On Mon, Sep 27, 2004 at 01:32:35PM -0400, Scott Palmer wrote:
> On Sep 27, 2004, at 12:30 PM, Jeremy Pereira wrote:
> >The underlying function that Josh Howe is asking for is to preserve a
> >copy of his tree as it was at the time of release 1.0.
> No it isn't. He is asking for a way to label a particular version of
> the tree. The copy is just cluttering the repository with something
> that needs more work to deal with. For example the tag needs to be
> protected from modifications with a pre-commit hook.
Which tree? The entire repository? That's the scope of a revision
number. A copy, on the other hand, can be made of any arbitrary subtree
of the repository: trunk, a release branch, etc.
> We already have a very similar concept to that of a labeled revision
> number: "HEAD", "BASE", etc.. Why is nobody suggesting to replace
> HEAD with repo/tags/HEAD ? (which could be deleted and recreated on
Because HEAD, BASE, etc. refer to the entire repository; when making a
release, even if you always release from the same repository subtree
(eg. trunk), you're referring to data by two "coordinates": location in
the filesystem, and revision number. By making a copy, you preserve
both of these coordinates, instead of only one (the revision number).
If you introduce the concept of a labeled revision that is limited to a
particular subtree, then I see no major difference between a copy named
'/tags/releases/1.0.0' and a "label" named '1.0.0 release'.
Of course, if you're proposing to do away with /tags, /branches, etc.
entirely, and just dump data in the root of the repository, then you
probably don't need to limit your scope to a specific subtree of the
repository; however, the existing usage of the subversion filesystem
seems to work well for many people, and I don't think that labeled
revisions will do away with it.
Software Engineer / Network Administrator
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Sep 30 15:31:05 2004