[XCSSA] Programming Source Control

xcssa@xcssa.org xcssa@xcssa.org
Mon, 20 Nov 2006 13:34:10 -0600


Subversion is quite mature and is easy to use, but it has a few 
shortcomings that keep me looking for alternatives. Here is a good 
summary of different open source version control systems:
   http://bazaar-vcs.org/RcsComparisons

 From the subversion book:
      "Ideally, your version control system should prevent the
      double-application of changes to a branch. It should automatically
      remember which changes a branch has already received, and be
      able to list them for you. It should use this information to
      help automate merges as much as possible.
      Unfortunately, Subversion is not such a system."

Problem 1:
    Since subversion does not track how branches are merged, it also 
means that "svn blame" (similar to "cvs annotate") may not tell you who 
really authored a line of code. If I write some confusing code, and Joe 
merges it into trunk (the production branch, by convention), "svn blame" 
will say that Joe added this code. Your only hope of tracking down the 
real author is if Joe was kind enough to comment which branch he is 
merging when he commits to trunk.

Problem 2:
   If you have a long running branch, and you need to merge in changes 
from trunk regularly so that you don't have one massive merge and the 
end of the project, then you have to keep track of which revisions 
contain changes from trunk versus changes from the branch. If you don't 
keep track of these revisions, subversion will try to re-apply patches 
it already has, which could have unintended results. Then you will have 
to merge revisions 40-55, but not 56, 57-60, but not 61, etc. To make 
the final merge into trunk simpler, you can continually branch from 
trunk, and merge all of your branch's changes into the new branch, so 
all of your changes will be a continuous range of revisions. Of course, 
if you do this and branch a bunch of times, it will be extremely painful 
to backtrack "svn blame" and revision logs to find the original author 
of any code. It will also be harder to revert a single change, since 
when you branch and merge in revisions 40-55, they become a single 
revision in the new branch.

-Edwin

xcssa-admin@xcssa.org wrote:
> xcssa-admin@xcssa.org wrote:
>> subversion is basically CVS with most of the drawbacks removed.
>>
>> Of course it implements branching as copies, so if you have a bunch
>> of branches it's not desirable.
> 
> A subversion tag is a read-only copy of the directory tree.  It's a copy 
> of the entries in the database, not an actual copy of the files.  When 
> you branch and commit, it will store diffs against the revision you 
> copied from rather than making an actual copy of all the files in a 
> whole new revision and starting from there.  That is actually very 
> desirable.
> 
>  From the subversion site:
> 
> "Branching and tagging are cheap (constant time) operations
> 
> There is no reason for these operations to be expensive, so they aren't.
> 
> Branches and tags are both implemented in terms of an underlying "copy" 
> operation. A copy takes up a small, constant amount of space. Any copy 
> is a tag; and if you start committing on a copy, then it's a branch as 
> well. (This does away with CVS's "branch-point tagging", by removing the 
> distinction that made branch-point tags necessary in the first place.)"
> 
> Nick
> _______________________________________________
> XCSSA mailing list
> XCSSA@xcssa.org
> http://xcssa.org/mailman/listinfo/xcssa