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.
Thanks for signing up for Jira Ops! I’m Matt Ryall, leader for the Jira Ops product team at Atlassian. Since this is a brand new product, we’ll be delivering improvements quickly and sharing updates...
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!
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