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 |
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.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |