Re: FW: [DESIGN] Aliases?

On Saturday 25 February 2006 12:24, Max Bowsher wrote:

> I'm sorry, but this most recent discussion doesn't appear to have
> covered any new ground compared with its previous incarnations.

True (alas).

> The proposed design replicates major disadvantages of the CVS model, for
> the sole advantage of shorter command lines;

Wrong, labels are not a disadvantage of CVS model, and even if they were,
adding them to Subversion does not give Subversion any disadvantage.

> * Unversioned: You can't tell who or when 'aliases' were created, nor
> track the history of an alias that undergoes changes.

Wrong, you can easily store a committer and date along with the label:

"VERS-2.2:rev12345:saulius:2006-02-26: etc. etc."

> * Unscoped: It would be far too easy for multiple projects in the same
> repository to clash on their alias naming.

Wrong, it is as easy (or as difficult) as not to clash directory of file names
for the multiple projects.

Not to mention that I find putting multiple (unrelated) projects into one
repository strange and inconvenient. Bu this is again a matter of personal
preferences.

> And, most of all, there is the conceptual weirdness of having two
> totally different UI paradigms for supporting the same goal.

Wrong, there is a conceptual weirdness in misappropriating branch mechanism
and special ad-hoc agreements (like "use 'branch/tags/main' repo layout") to
emulate missing tags.

> Regarding the specific example of merge tracking which seemed to be the
> major justification employed in the users@ thread: This is _entirely_
> possible with properties - indeed, see svnmerge.py in contrib/ for a
> very nice front-end to merging, which does far more than is
> accomplishable with 'aliases'.

The argument "you can already do it by using xyz workaround" does not go.

Taking it to the extreme, you could equally argue thatg version control was
possible long before Subversion, and long before any other VC tool for that
matter:

cp -a project/trunk ChangeLog project/revision-1234

so Subversion should be considered obsolete.

Conceptually, Subversion does the same thing, if you want. It is the
efficiency and convenience that we gain by using Subversion. So naturally
there is a wish to straighten all remaining "rough edges".

Regards,
Saulius

-- 
Dr. Saulius Grazulis
Institute of Biotechnology
Graiciuno 8
LT-02241 Vilnius
Lietuva (Lithuania)
fax:          (+370-5)-2602116
tel.: office: (+370-5)-2602556
      mobile: (+370-684)-49802, (+370-614)-36366