Why can't Crucible handle a SVN lazy copy

[Brent Webster]

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?

[Felipe Kraemer]

Hello,

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

[Brent Webster]

Disappointing.

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.