[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: feature request: svn revision alias

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: Thu, 21 Feb 2008 08:38:47 -0500

> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning_at_Dell.com]

>
> >>>>> "David" == David Bicking <Bicking> writes:
>
> >> -----Original Message----- From: Paul Koning >>
> [mailto:Paul_Koning_at_Dell.com]
>
> >> >>>>> "David" == David Bicking <Bicking> writes:
> >>
> David> Alright, I'm going to be more explicit. How would
> >> you name a David> revision, knowing that it applies to the
> whole >> repository, in David> such a way that it offers any
> kind of >> meaning? The name David> "V3.14_baselevel3"
> appears to identify a >> particular branch of David> a
> particular project. To me, this is >> adding confusion,
> David> because that revision is global and might >> apply to
> David> "V7.24.032_tertiarylevel1" on another project.
> >> So, once more, David> what can the alias tell you that
> has more >> (and concise) David> meaning than the revision
> number given its >> global nature?
> >>
> >> Part of the answer is that a given repository doesn't
> contain >> things that are utterly unrelated.
> >>
> >> The main answer is that I would use symbolic name >>
> "V3.14-baselevel3" only when poking around the part of the
> >> repository that holds V3.14. Yes, that same name (the
> revision >> number it refers to) is also meaningful in other
> parts of the >> repository. But clearly it would be silly
> for a user to say "show >> me the sources of GCC as they
> were in the rev that created >> Subversion 1.91-RC2".
> >>
> >> paul
>
> David> Okay, that is what I thought. The problem that I
> (personally) David> see with that is there is an implicit
> assumption that a single David> repository will only contain
> directly related projects, that David> have no branching, or
> it assumes a particular path is David> implicitly assocated
> with the alias, which is what Tags do David> coupled with
> its revision number.
>
> I can't see how you get there from what I wrote. I certainly
> didn't say those things, and I don't assume those things. In
> fact, I thought I clearly said I assume very different things.
>
> paul
>

Alright, then tell me how a new user of the system knows by looking at
an Alias, without external documentation or coaching, that
"V3.14-baselevel3" is only relevant to
"/Proj1/branches/customer1_billing_system"? If you attach a path to the
Alias, you now have a one to many relationship with revision number,
which changes the enitre premise of the request.

I submit that although it would be silly - as you say - to associate
"Subversion 1.91-RC2" with GCC, that there is no way other than external
business knowledge or savvy cognitive skills to make that determination,
and worse, this depends on the alias creator having a flawless ability
to name revisions in such a way as to preclude any confusion, ever
(assuming the intention is to allow new users to view the repository
without special coaching).

Further, I believe it also leaves out the reality that "Subversion" may
have more than one active codeline. Does "Subversion 1.91-RC2" refer to
"trunk" "branches/experimental", "branches/svn_ver1",
"branches/svn_ver1.5", etc.? I would obverve that structure and
conclude it is either "trunk" or "branches/experimental", possibly
"branches/svn_ver1.5" because it is the closest revision number to the
alias. I could be wrong on all guesses, depending upon the intention of
the person who set the alias.

I'm simply saying that such a feature leaves much up to interpretation
by individual teams and is information that cannot be difinitive, clear,
and concise just by looking at the repository.

--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-21 14:39:18 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.