> 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.
> 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.
> 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.
> 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.
Moreover, i also overlooked the following, which does not directly
apply to the PML label feature but rather to the way that for example
the svn toolchain gives access to the label information:
Say for example that file F1 has been changed at revs 7 and 15 and
that HEAD currently is 18. Now i attach the PML "Rel 1.0" to rev 10
and the PML "Rel 1.1" to rev 18. Now i want to see that F1 has seen
changes at revs 7 and 15 (which is already supported via "svn log")
and that there were labelled revisions *between* 7 and 15 and *after*
15. By piecing this information together, i know that the F1 change
at rev 7 was released with release 1.0 of my product and that the
F1 change at rev 15 has been released with 1.1, so if the F1 change
at rev 15 introduced a bug, then i know that release 1.0 doesn't have
the bug yet, which is what i'm aiming at.
I'm thinking of a new subcommand (called for example "svn labels")
which would quickly list all labels that have been set on the repo
globally.
Tools such as TortoiseSVN could easily merge this information with
the current output of "svn log", yielding the information that i
need and reducing the need to issue "svn log" on the repo root or
on other non-trivial repo parts with lots and lots of
added/changed/deleted files, which is sometimes painfully slow!
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 22 09:49:34 2006