Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

subversion



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.

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 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.

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.

            - Jim Van Zandt


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





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org