-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lan Barnes wrote: > Also, the lack of true tags/labels is a chronic gripe for me with svn. The > developers insist that their hokey use of the copy facility to make > instances that, they say, can stand as labeled versions, is all anyone > needs. But this is the exact same rhetoric we heard from the cvs > developers when the svn people were criticising their refusal to address > certain cvs deficiencies.
What do you see as the real difference between tags/labels and a copy? I tend to like the svn way (having never really used the CVS tags, so I'm curious as to their advantages) because it is consistent with how everything else works and is not a special case in the system like CVS tags. Everything is a tree and if you want to set aside some chunk of code with a special label you can do so. I would much rather refer to a certain url when I need to check out a particular tag/label than have to remember a special command line option so that I can specify the tag I want. It just seems more intuitive to someone who has never really used version control before and works just as well from an interface point of view. I have been exposed to CVS for years. But having to set environment variables and use strange command line options made it always seem a bit wonky. Now I use CVS occasionally in my job (although I personally use svn quite a bit more) and have learned a lot more about it, mostly due to the cvs vs svn debate. :) When you are navigating a CVS source repository how are tags represented? It seems like they are always a weird special case. I can imagine a tree (a la svn) quite well. I can't imagine how navigating tags in CVS would work nicely without more special hacks. > I could see something like svn WITH TRUE TAGS being quite adequate for > controlling boiler plate documents like legal contracts. But without tags, > you would be reduced to trying to anticipate and save every possible > instance of any document that might be asked for, which defeats the > purpose of dividing the documents into clauses. Wouldn't you have to anticipate and tag every instance of every document that might be asked for in cvs? Seems like the same thing by a different name to me. In cvs you can end up with a zillion labels on each file. In svn you can end up with a zillion branches/copies. It ends up being the same thing just refactored differently. The copies in svn are really just pointers anyway so it's not like it takes up any more space to do it that way. But it seems the svn way has some advantages. In svn, making a tag (copying a directory) is an O(1) operation, it's nearly instantaneous. In cvs, if you 'tag' a big tree you could wait minutes or hours for the label to be applied to each file. It is O(N). In svn, it's nice to have your tags exist as directories. Because then you can access control them (which is impossible in cvs afaik). And as I mentioned before you can more easily navigate them. I can more easily navigate and understand a repo presented by trac ( http://trac.edgewall.org/ ) than one presented by the most common cvs interface which seems to be cvsweb. Look at a cvsweb site. Notice how they have to have a special pulldown menu where you can select which tag it is you want to see because tags don't really fit in to a hierarchical model. Plus in svn you can rename them, move them around, reorganize them and browse them which cvs makes infamously difficult. As I'm sure you know, it's a convention (but not a requirement!) in svn repositories to have /trunk, /branches, /tags directories at the top of a repository. People create their own interesting hierarchies of tags under /tags, typically. So things tend to stay pretty well organized. Either way, both systems achieve a snapshot as desired. - -- Tracy R Reed http://ultraviolet.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFzpNB9PIYKZYVAq0RAmMCAJ9MCasmjKVS0AWlcyFrk64n3sWkQACfRVQO FsIjEJClTcVQykTH7LL+CCU= =Uq4R -----END PGP SIGNATURE----- -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
