Yes, you have. Perhaps I should have been more clear.
The *summary* in the first part of my email was intended to make the
point that it would be useful to add these restrictions to the proposal
since it further defines the intended scope of the solution, thereby
avoiding feature drift.
The second point I tried to make was that there is the suggestion of
two discrete groups of people: simple users that would use labels and
advanced users that would use tags. That seems to be a significant
simplification of the world at large. Furthermore upgrade issues will
I think these three issues wil have to be dealt with *in the proposal*
if the ultimate goal is to write a proposal that would convince the
existing Subversion developers.
Gerco (only trying to be constructive).
Tim Hill wrote:
> Frankly, I've discussed these issues in an earlier post, where I made
> clear my opinions on pretty much all of this.
> On Nov 23, 2006, at 5:18 AM, Gerco Ballintijn wrote:
>> Tim Hill wrote:
>>> I cannot talk for others, but my intention has _never_ been to
>>> replace tags with labels, for the very reasons you state. However,
>>> you are talking about _your_ usage model for subversion. There are
>>> many, many installs where Subversion is used as little more than a
>>> historical time-machine for a simple, linear, development cycle. In
>>> these simple scenarios there is _NO_ "path" co-ordinate to manage,
>>> since there are no branches at all: everything happens on the trunk
>>> (yes, really!).
>> I assume you also "require" that only a single "project" is maintained
>> per repository.
>> The workflow context of your proposol would thus be:
>> - Single project per repository
>> - No branches
>> - No tags
>> This means that your "simple" users should be kept away from Subversion
>> documents that describe these techniques. I am not so sure that you can
>> contain your (and not just your) users in this simplified Subversion
>> Have you considered the "upgrade" problems? People that think they can
>> suffice with labels, but at a later require more functionality and
>> need the current tagging mechanism. For instance, because they want to
>> add an extra project to the repository, and thus have projects that
>> share the same label name space? I expect this to an extra source of
>> As a side note, it is a "policy break" in Subversion that two over-
>> lapping concepts (in this case actually one a subset of the other), get
>> different mechanism to satisfy different user groups. I can imagine that
>> the Subversion stewards would find this a dangerous precedent (the
>> slippery slope argument).
>> With regards,
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Nov 24 13:56:33 2006