[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