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 |
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 | |
We also thank MIT for the use of their facilities. |