Re: FW: [DESIGN] Aliases?

--nextPart1821495.sHDHDD6eY3
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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,=20
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 na=
mes=20
for the multiple projects.

Not to mention that I find putting multiple (unrelated) projects into one=20
repository strange and inconvenient. Bu this is again a matter of personal=
=20
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=
=20
and special ad-hoc agreements (like "use 'branch/tags/main' repo layout") t=
o=20
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=
=20
possible long before Subversion, and long before any other VC tool for that=
=20
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=20
efficiency and convenience that we gain by using Subversion. So naturally=20
there is a wish to straighten all remaining "rough edges".

Regards,
Saulius

=2D-=20
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

--nextPart1821495.sHDHDD6eY3
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBEAOq9MH1yPuFyq3QRAsBSAKCu0JnqhMGBzsKkRERa72ZWX4PDDQCcCDqJ
g2bz+lP1948rCTBmYvVd8kk=
=UaPB
-----END PGP SIGNATURE-----

--nextPart1821495.sHDHDD6eY3--