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.
2. How many labels can be attached to a revision? One? Any number?
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)?
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?
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?
I think I know what I would answer to the above, just canvasing other
input.
--Tim
On Nov 21, 2006, at 6:29 AM, Robert Graf-Waczenski wrote:
> I *very much* second the proposal to start a discussion about
> simple labels. So, to get this right from the beginning, i'll
> first coin a snappy term and then describe the features i need:
>
> Poor Man's Label "PML"
> ----------------------
>
> 1) A PML can be attached to any existing revision, similar to
> revision properties.
>
> 2) If a PML was attached to a revision, then this PML can be
> used in any svn toolchain command as an alias for that specific
> revision and when the rev# is displayed in a history log, then
> the PML should be displayed next to it, if there is one.
>
> 3) Existing PMLs can be edited in any desirable way, including
> editing of the PML text and removing the PML.
>
> Robert
>
>> -----Original Message-----
>> From: Tony Harverson [mailto:tony.harverson@iglu.com]
>> Sent: Dienstag, 21. November 2006 14:14
>> To: Subversion Users
>> Subject: Simple Label=RevisionID Discussion
>>
>>
>>> -----Original Message-----
>>> From: Robert Graf-Waczenski [mailto:rgw@lsoft.com]
>>>
>>> Don't throw the word "branch" into this discussion! The issue
>>> at hand evolves around SVN's notion of "tagging" compared
>>> with various levels of a yet-to-be-defined support for
>>> labels, revision aliases, revision indexes or whatver else
>>> they have been called.
>> You're right, I meant "Tag" instead of "Branch". The Comment
>> should have read:
>>
>> "Yup, but that would be a tag, which is contended to be too
>> complex/complicated for non technical users or some of the projects
>> under discussion here. This discussion has the precept
>> that users do not want to copy off to another folder location, but
>> want
>> to replace that functionality with a labelling feature set which
>> is easier to use."
>>
>>> *don't* want to get rid of using branches! But still we would
>>> benefit from label support in SVN (in our case: from trivial
>>> repo-wide revision aliases, we don't need the more complex
>>> variants that others have described and which arguably
>>> overlap with what the SVN devs intended with the "tag" concept.)
>>
>> We desperately need to sever the various discussions in here,
>> because we're chasing our tails discussing blurry and moving
>> targets. *Your* requirement is for a simple revision = label
>> mapping. The comment I replied to was in reply to a discussion
>> about complex tags/labels, which is a semi-separate discussion.
>>
>> If the simplest concept of a label (revision ID = "Label") was
>> implemented, it would be useful for (for example) tagging the
>> stable and production versions of an ongoing project. It would
>> not, however, be useful for labelling releases, which seems to be
>> the other requirement which is being loaded onto it. ( For
>> reasons already covered in this thread, there's nowhere to commit
>> fixes to in the second case, and the requirement becomes for
>> complex tags, which is another discussion.
>>
>> T
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: users-help@subversion.tigris.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 21 17:03:40 2006