On Nov 22, 2006, at 12:49 AM, Robert Graf-Waczenski wrote:
>> ok, let's flesh out the details...
>>
>> 1. Label syntax: what are the allowed set of characters in a label?
>> Bear in mind that they need to be injected back into command-lines,
>> so there are some restrictions if they are going to be parsed
>> unambiguously.
>
> Even though i think that US-ASCII would be sufficient for my purposes,
> i don't see why full UTF-8 should cause problems even if it would be
> used in the command line. If commit messages are restricted to less
> than UTF-8 for this particular reason, then i'm fine with that.
I think at least a few "special" characters need to be disallowed
(e.g. double quotes) as otherwise parsing the command-line and/or
parsing any "svn list-labels" command becomes a nightmare.
>
>> 2. How many labels can be attached to a revision? One? Any number?
>
> Only one. (Remember, we're talking *poor* man's labels here...)
>
>> 3. When are labels attached? Using a discrete comment? Using a new
>> commit-time switch (which would need to include other "commit" type
>> commands like copy/import)?
>
> I'm not sure what you mean here. The label should be attachable any
> time to any revision that exists in the repo.
Sorry, I meant "discrete commit", i.e. set a label via "svn label"
command, rather than "svn commit ... -label ...". Of course, you
could have both.
>
>> 4. You are proposing mutable labels. Is this safe? Should the system
>> only allow a label to be changed if some sort of --force switch is
>> also supplied?
>
> Yes, labels should be mutable, they should be changeable without any
> additional --force switch being supplied. (However, i find that SVN's
> current default behavior of not allowing revision property changes
> without
> the pre-revprop-change commit hook being implemented would do well
> for handling label text changes.)
> Sure, if projects fiddle with the label texts and forget to adjust
> their build scripts, their builds will fail. But i don't think that
> this is a problem of SVN's. To SVN+PML(TM), a PML is a revision alias
> (which is enforced to be unique, see below), nothing more.
To an extent, I agree. BUT this is a significant departure from SVN
as it currently exists. Today, SVN gives a strong guarantee about the
behavior of past revisions. If, at one time, a rev# represented a
certain snapshot state of a project then the idea is that it _always_
represents that state. Thus, I can "wind-back" time and always (for
example) rebuild an older rev of a product, assuming I track/audit
the rev#s (which, I grant, would be easier with labels). Tags are an
explicit presentation of this concept.
There are only two ways today to break this contract: an admin can
delete a rev from a repo (but that's an admin thing, not a regular
user), or a revprop can be changed, but this is disabled by default
precisely because it breaks the snapshot contract.
>
>> 5. If rev N has label X can ren M have the same label? How should the
>> tools behave in such a case when choosing a rev# based on label?
>
> That's something i actually overlooked. You are right, label texts
> must
> be unique, i.e. if rev N has label X, then rev M can not have the
> same label.
In fact, I think the answer is that you *can* have the same label
reused multiple times. The default behavior should then be for
Subversion commands to use the _newest_ instance of that label when
it is specified in the --revision switch. This allows a newer re-use
of the same label to "shadow" the earlier use. If you want to get the
earlier label, you simply use a peg revision to get to the earlier
part of the tree.
Note that this also solves the mutable problem: labels can be re-used
without needing to be mutable. Also, if you allow multiple labels per
rev#, then I think there is _never_ a need to delete a label from a
rev#.
For example:
svn label "foo-lab" # Label the head revision (200) with "foo-lab"
svn label "rev150" --revision 150 # Label for rev 150
svn label "foo-lab" --revision 100 # Label a prior revision with
"foo-lab"
svn label "bar-lab" --revision 100 # .. and "bar-lab"
Now:
svn co foo.c -r "foo-lab" # Gets foo.c from rev 200
svn co foo.c -r "bar-lab" # Gets foo.c from rev 100
svn co foo.c@"rev150" -r "foo-lab" # Gets foo.c from rev 100
Note the last command: the peg-revision directs subversion to begin
searching at rev# 150, so the newest "foo-lab" in this case is rev 100.
I think the command-set for labels would pretty much match that for
revprops:
-- Command to set a label against a rev# (default, HEAD):
svn labelset <name> [--revision ...]
-- Command to get the rev# that corresponds to a label:
svn labelrev <name> [--revision ...] # --revision is used to
specify a start-point for the (backward) search (like a peg revision)
-- Command to list all labels in a rev# range:
svn labellist [--revision N:M] # Default N:M = 1:HEAD
Of course, the --revision switch could take labels as arguments.
Also, svn commands that display rev#s should be able to display
labels with the addition of a --label switch (so existing parsers
don't break).
Finally, since labels are global, the ability to _set_ them should be
under the control of the server. Either via a new authz declaration
(in addition to read, write and none), or via a hook script (or both).
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 22 18:32:15 2006