Why can't Crucible handle a SVN lazy copy

Before Crucible, my designers did the following:

  1. Checkout out source code from a svn repository in their working copy(WC) where they can make changes and keep up to date with that branch via 'svn update'
    Disadvantage is they cannot perform intermediate checkin of source code but this process is fine for short term bug fixing.
  2. When the designer is ready to code inspect, they perform an 'svn update' to align the code with the latest submissions.
  3. The from the WC directory, a svn lazy copy is performed to a private branch where it will be automatically checked out
    i.e. svn copy . http://my.com/svn/BA/branches/review/Brent/stuffToBeReviewed

If I use TortoiseSVN, it understands svn's lazy copy concept and only shows the files that were actually changes. These files can be selected and their diffs displayed.

If I use Fisheye and "Go to changeset" for this stuffToBeReviewed branch, it shows every file in the branch whether changed or not and no diffs are available, only the entire file is displayed.

Am I missing a concept or am I forced to create a "working" branch first, check out that "working" branch into a WC, then check the changes from the WC back into the "working" branch before I can get the diffs?

1 answer

0 vote


Subversion has a feature called cheap copies:

Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects.

This is why you'll often hear Subversion users talk about "cheap copies." It doesn't matter how large the directory is—it takes a very tiny, constant amount of time and space to make a copy of it. In fact, this feature is the basis of how commits work in Subversion: each revision is a "cheap copy" of the previous revision, with a few items lazily changed within. (To read more about this, visit Subversion's web site and read about the "bubble up" method in Subversion's design documents.)

Of course, these internal mechanics of copying and sharing data are hidden from the user, who simply sees copies of trees. The main point here is that copies are cheap, both in time and in space. If you create a branch entirely within the repository (by running svn copy URL1 URL2), it's a quick, constant-time operation. Make branches as often as you want.

Although in SVN directly these cheap copies take a very small amount of time to be processed and a small disk space, the FishEye documentation says:

The more often you make major changes to the structure inside your SCM, the more scanning is required for FishEye to keep track of its status. This especially applies to Subversion, because of its concept of 'cheap copies'. The result is that small changes can be essentially unmeasurable and cause a large amount of re-scanning.

So, answering your question:

The SVN commands executed in the command shell are executed against SVN directly and, as explained above, they take a small amount of time to be processed. FishEye uses a different architecture, in which these commands can take a large amount of time to be processed, depending on how many branches and tags you have and how large they are. That's why we suggest in our Best Practices documentation to split your repositories into logical components if you can.

Kind regards,
Felipe Kraemer
Atlassian Support


When part of the solution is to break up your repository because a tool can't handle the current situation then that is not really a solution. Tools should not drive the process, the tool should adapt to a process.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published yesterday in Jira Software

How large do you think Jira Software can grow?

Hi Atlassian Community! My name is Shana, and I’m on the Jira Software team. One of the many reasons this Community exists is to connect you to others on similar product journeys or with comparabl...

312 views 4 9
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you