>>
>
> I hope you can see as clear as I do that people are trying to
> evolve your "PML" into a full blown secondary tagging mechanism.
> What I like about svn is that there is a simple way of doing
> things, creating a tag. It's really dead simple, I make a copy,
> just as I used to do back when noone was talking about revision
> control: place a backup somewhere. Creating a secondary tagging
> mechanism makes the whole thing go from sleek and efficient to
> bloated and overburdened. I agree that some workflows can be
> streamlined and that some paradigms are sometimes awkward for small
> scale projects but I really prefer it over ambigious behaviour and
> tons of options, multiple ways of doing things.
>
> I understand that your intention is to make things better and
> simpler, but often the worst things stem from purely good
> intentions. I'd rather prefer to map the simpler workflows we both
> want to the "regular" workflows and hide that fact from the user.
> The tortoiseSVN "tag" command is just this example. It does offer a
> nice interface to tagging and in the background creates a copy.
>
Yes, I do see this, and it's pretty normal for any new feature to
initially bloat as people try to bolt on all sorts of edge cases.
Myself I always apply the 80:20 rule (80% of use cases are satisfied
by 20% of the proposed features).
In fact, if you look carefully at my previous proposal, you'll notice
that, in fact, its just really a slightly disguised revision property
with some command-line sugar. I like this because (a) it gives people
labels, (b) it doesn't change the repository schema or protocol and
(c) its fully forward and backward compatible.
My thinking goes like this:
-- A "label" is a symbolic name for a revision. Therefore its a
property of a revision. Therefore its a revision property.
-- BUT revprops are, by default, disabled in Subversion, since they
can break old revisions by making retroactive state changes.
-- BUT a label (revprop) that is set _only_ at commit time (i.e. when
the rev is created) does NOT have this flaw.
-- Therefore, the need is for relaxing the revprop rules such that
they _can_ be set at commit time, but otherwise follow the same
restrictions as currently.
-- Therefore, Subversion needs the ability to set revprops atomically
at commit time.
So, we have something like this:
svn commit ... --revprop name "VALUE"
Which does a commit and includes the named revprop.
And I really think that's it! Yes, using labels in rev#s would be
nice, but not necessary.
--Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 22 22:07:32 2006