Before Crucible, my designers did the following:
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?
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.
Hello Insight users, As part of our (Mindville's) acquisition by Atlassian, our training team is looking to build some new Insight training materials. It would really helpful if you can ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event