> 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.
>
> With regards,
> Gerco (only trying to be constructive).
Succeeded. (At least for me..)
> > 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
I don't see why you think that the workflow context would be such that
the intended user type would not use branching. Yes, Tim describes a
scenario were everything happens on the trunk. Clearly for such a scenario
the proposed PML would be a fine mechanism re-create older builds
by referring to old rev#s with a revision alias.
But also a project such as the one i'm working in since several
years would benefit from PMLs because this would free us from the
need to create tags. We *need* branches simply because we have
several releases to maintain in parallel, so there definitely is a
space co-ordinate to manage. We would like to use SVN without tags
but instead with PMLs that point to the correct time co-ordinate.
And, to us, this time co-ordinate is meaningfull in all branches.
My goal with this proposal is to make the implementation close to
trivial and the benefit as high as possible, so any comment is welcome
that refines the proposal in such a way that the developers feel good
about adding it and also don't see too much side effects in the
implementation.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 24 14:25:42 2006