[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Mnemomic names for revisions

From: Brian Huddleston <brianh_at_huddleston.net>
Date: 2005-05-10 02:54:41 CEST

First of all I apologize for the use of the word "unsafe" if I used it. :-)

> The only way to guarantee label immutability is to make it a piece of
> versioned metadata attached to the revision.

Yeah...that's more or less what I was thinking as far as the "simple
design". (Leaving aside some of the more ambitious "label" ideas.)

>That means the label would have to be chosen at commit time. I don't
>think anyone wants that design; it means that labels couldn't be applied

Well, I obviously know zilch over squat about how things are put together
under the cover, but I was thinking more along the lines of a "write once"
property. You can set it on any revision, but once set, any attempt to
set/change it would result in an error.

> If the design allows labels to be applied retroactively, then it also
> necessarily allows labels to be *accidentally* changed. Exactly like the
> current implementation of tags.

Well, if it was unclear, I was fiat-ing that the server would catch a second
propset as an "error". The first time your set svn:label on revision 1234
you would succeed. The second time you set svn:label on revision 1234 you
would get an error. (Then we presumably allow some sort of --force if
people sincerely did screw up.)

I'll leave arguments about whether special casing behavior for a particular
revision property is wise/elegant/advisable/possible to people, such as
yourself, who actually understand how the system is put together under the
cover. This is simply a naive feature request bundled with a naive
implementation suggestion. :-)


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 10 02:56:31 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.