subversion

[david at thekramers.net (David Kramer)]

James R. Van Zandt wrote:
> Tom Metro <blu at vl.com> wrote:
>>   I haven't looked into this, but I'm not sure why tagging wasn't 
>>   implemented through some convention of setting attributes on the 
>>   repository, given that Subversion has that ability.
> 
> When I scanned the SVN book, I thought tagging was one of the
> important missing features.  SVN claims that a tag is a special kind
> of copy (that is, a copy with "tag" in the directory name).  I think
> it makes more sense to treat a tag as a special name for a specific
> version of a branch.  So a branch and a tag should have different
> semantics.  It should be possible to commit changes to a branch
> without affecting the identity of the tag.  It should also be possible
> to review the history of a branch and see all the versions that are
> tagged.

This is getting silly.  You can do this in Subversion.

> But the more important missing feature is intelligent merging, as John
> Goerzen describes in his review:
> 
>>   3. Merging between branches is intelligent. It should be easy to
>>   merge another branch with your own. The VCS should know which
>>   changesets from the other branch are already on yours, and should
>>   not attempt to merge changesets that you have already merged
>>   previously.
> ...
>>   Merging between branches in svn is really poor, and has no support
>>   for recognizing changesets that have been applied both places,
>>   resulting in conflicts in many development models.

I have relied very heavily on svn merging at several jobs and found it
plenty powerful, even in the website secnario I mentioned, where ALL
changes to the live website were accomplished with svn merge commands.

> I think when a source code control system applies a changeset to a
> branch, it ought to record the original explanation in the log,
> together with enough context that in a later merge in either direction
> it can avoid re-applying that changeset.  Even if the relevant code in
> the two branches differs.  That is, after resolving the conflicts, the
> programmer is asserting that the changes in the two branches have the
> same effect.

Personally, the way I handled the whole svn merge and svn copy
documentation issue was to paste the svn command issued right into the
comments for the commit.  This was very easy to do and completely
unambigous.  Of course, like I said, Subversion tracks it for me (as
I'll explain below), but this way I can clearly see in the logs what was
done when.

> Someone wrote that in SVN, versions are real and changesets are
> derived (i.e. diffs).  I'm arguing that changesets need their own
> semantics, so the system can remember when changesets in two branches
> are equivalent, even when their diffs are not the same.

Not exactly.  Since all files in the repository have the same revision
number at any given time, every single commit is a changeset.

And Subversion *does* keep track of their lineage.  If you do an svn
copy, then do an svn log on that copy, you have the choice of following
the changed back to where the copy was made, or continuing back into the
log from where it was copied.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.