You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by OS <os...@portfoolio.com> on 2008/02/18 05:18:33 UTC
feature request: svn revision alias
Hi all,
Like probably a great many users out there, I'm very happy with svn --
thanks for a great product!
But the tag-via-copy mechanism continues to confuse my users, in
particular new ones.
They keep pointing out how different this is from other systems (they do
love the branch-via-copy though).
A particularly stubborn fellow has actually forced us to implement a
different mechanism for his project
where we keep a separate file that links svn revisions to symbolic
names. (Fortunately, he was happy
with just that)
And that made me think whether it would be difficult to implement that
in svn natively.
The svn revision is pretty much equivalent to what a tag is in other
systems.
But it's a numeric value, hard to remember, etc -- and people wish to
give tags descriptive names.
Wouldn't this be useful:
svn alias <rev> <name> (or svn revalias <rev> <name>)
Then one would be able to use <rev> and <name> interchangeably in other
svn operations.
Call it the poor man's svn tag! :)
I don't know... But it appears simple enough to implement (please excuse
my ignorance), and I think
many people out there would love this feature. (At least judging by my
pesky users!)
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: feature request: svn revision alias
Posted by OS <os...@portfoolio.com>.
Yes -- once again, others seem better at explaining my use cases :)
>It would be up to the user to know which directory tree that the alias applies to. Kind of like how svnmerge.py requires that you know which top level dir contains the merge properties. =)
>
>The benefit would be in being able to:
> svn co -r REL.1.0.0 svn://url/trunk
> svn log -r REL.2.1.3 svn://url/trunk
> svn co -r LOGGING_1.0.0 svn://url/logging/trunk@LOGGING_1.0.0 (Peg revision)
>
>My inner ClearCase junkie is starting to see some usefulness in 'svn alias' as a way to do an in-place tag.
>
That's why I called it the poor man's tag :)
(And sorry about the msg format -- I use plain vanilla Thunderbird)
Cheers.
Reedick, Andrew wrote:
>>From: Bicking, David (HHoldings, IT) [mailto:David.Bicking@thehart
>>ford.com]
>>Sent: Wednesday, February 20, 2008 3:33 PM
>>To: OS
>>Cc: Reedick, Andrew; users@subversion.tigris.org
>>Subject: RE: feature request: svn revision alias
>>
>>How would you name a revision, knowing that it applies to the whole
>>repository, in such a way that it offers any kind of meaning? The
>>name "V3.14_baselevel3" appears to identify a particular branch of
>>a particular project. To me, this is adding confusion, because
>>that revision is global and might apply to
>>"V7.24.032_tertiarylevel1" on another project. So, once more, what
>>can the alias tell you that has more (and concise) meaning than the
>>revision number given its global nature?
>>
>>
>
>
>It would be up to the user to know which directory tree that the alias applies to. Kind of like how svnmerge.py requires that you know which top level dir contains the merge properties. =)
>
>The benefit would be in being able to:
> svn co -r REL.1.0.0 svn://url/trunk
> svn log -r REL.2.1.3 svn://url/trunk
> svn co -r LOGGING_1.0.0 svn://url/logging/trunk@LOGGING_1.0.0 (Peg revision)
>
>My inner ClearCase junkie is starting to see some usefulness in 'svn alias' as a way to do an in-place tag.
>
>
>Even better, if the alias also saved the associated URL:
> svn alias -r 1234 LOGGING.1.0.0 svn://repos/logging/trunk
>then you could have commands like:
> svn co LOGGING.1.0.0
> svn log LOGGING.1.0.0
> svn copy LOGGING.1.0.0 svn://server/logging/branches/rel.2.0
>which would mostly mimic the in-place tagging of traditional systems. However, you wouldn't be able to move tags on individual files.
>
>
>In either case, you would need the ability to lock down aliases to prevent idiots, the well-intentioned, and managers from changing or destroying an important alias.
>
>
>
>
>
>
>>(and I guess you can't send ASCII posts -too bad)
>>
>>
>
><tinfoil_hat>
>I'm pretty sure that Microsoft deliberately makes html email appear (and stay) in Outlook's top-posting, indented format. Since they cannot push RTF upon the world, they're trying to push the Outlook email format paradigm in order to build mind-share in their locked-in market and sue any 3rd party program that uses the Patented Proprietary Outlook Email Format.
>
>IMHPO (in my humble paranoid opinion)
></tinfoil_hat>
>
>
>
>*****
>
>The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
>
>
>
>
>
>
>
RE: feature request: svn revision alias
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
>From: Bicking, David (HHoldings, IT) [mailto:David.Bicking@thehart
>ford.com]
>Sent: Wednesday, February 20, 2008 3:33 PM
>To: OS
>Cc: Reedick, Andrew; users@subversion.tigris.org
>Subject: RE: feature request: svn revision alias
>
>How would you name a revision, knowing that it applies to the whole
>repository, in such a way that it offers any kind of meaning? The
>name "V3.14_baselevel3" appears to identify a particular branch of
>a particular project. To me, this is adding confusion, because
>that revision is global and might apply to
>"V7.24.032_tertiarylevel1" on another project. So, once more, what
>can the alias tell you that has more (and concise) meaning than the
>revision number given its global nature?
It would be up to the user to know which directory tree that the alias applies to. Kind of like how svnmerge.py requires that you know which top level dir contains the merge properties. =)
The benefit would be in being able to:
svn co -r REL.1.0.0 svn://url/trunk
svn log -r REL.2.1.3 svn://url/trunk
svn co -r LOGGING_1.0.0 svn://url/logging/trunk@LOGGING_1.0.0 (Peg revision)
My inner ClearCase junkie is starting to see some usefulness in 'svn alias' as a way to do an in-place tag.
Even better, if the alias also saved the associated URL:
svn alias -r 1234 LOGGING.1.0.0 svn://repos/logging/trunk
then you could have commands like:
svn co LOGGING.1.0.0
svn log LOGGING.1.0.0
svn copy LOGGING.1.0.0 svn://server/logging/branches/rel.2.0
which would mostly mimic the in-place tagging of traditional systems. However, you wouldn't be able to move tags on individual files.
In either case, you would need the ability to lock down aliases to prevent idiots, the well-intentioned, and managers from changing or destroying an important alias.
> (and I guess you can't send ASCII posts -too bad)
<tinfoil_hat>
I'm pretty sure that Microsoft deliberately makes html email appear (and stay) in Outlook's top-posting, indented format. Since they cannot push RTF upon the world, they're trying to push the Outlook email format paradigm in order to build mind-share in their locked-in market and sue any 3rd party program that uses the Patented Proprietary Outlook Email Format.
IMHPO (in my humble paranoid opinion)
</tinfoil_hat>
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning@Dell.com]
>
> >>>>> "David" == David Bicking <Bicking> writes:
>
> >> -----Original Message----- From: Paul Koning >>
> [mailto:Paul_Koning@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by Paul Koning <Pa...@dell.com>.
>>>>> "David" == David Bicking <Bicking> writes:
>> -----Original Message----- From: Paul Koning
>> [mailto:Paul_Koning@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning@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
Okay, that is what I thought. The problem that I (personally) see with
that is there is an implicit assumption that a single repository will
only contain directly related projects, that have no branching, or it
assumes a particular path is implicitly assocated with the alias, which
is what Tags do coupled with its revision number.
--
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by Paul Koning <Pa...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
Alright, I'm going to be more explicit.
How would you name a revision, knowing that it applies to the whole
repository, in such a way that it offers any kind of meaning? The name
"V3.14_baselevel3" appears to identify a particular branch of a
particular project. To me, this is adding confusion, because that
revision is global and might apply to "V7.24.032_tertiarylevel1" on
another project. So, once more, what can the alias tell you that has
more (and concise) meaning than the revision number given its global
nature?
(and I guess you can't send ASCII posts -too bad)
--
David
________________________________
From: OS [mailto:os@portfoolio.com]
Sent: Wednesday, February 20, 2008 2:44 PM
To: Bicking, David (HHoldings, IT)
Cc: Reedick, Andrew; users@subversion.tigris.org
Subject: Re: feature request: svn revision alias
I did (in fact, Paul Koning did):
I don't think of a tag that way. Instead, I view it as
a name for a
point in the history of my code.
So one day I may say "I'd like to see the code for "ls"
as it was in
the baselevel tagged "V3.14_baselevel3" and another day
I may go
looking for the code of another piece with that same
tag.
To do that, I'd ask Subversion for the subtree in
question as it was
in that rev. Right now I'd use a numeric rev; with
aliases I could
use a named rev.
Bicking, David (HHoldings, IT) wrote:
First, can you find a way to send your posts in ASCII?
My Outlook insists on top-posting these unless I convert to text, which
produces the bizarre formatting seen in Andrew Reedick's reply (and I
chose not to do that this time around).
Second, you did not answer the question that comes with
option (a): what is the benefit? How would you name such a revision if
you maintain multiple projects in a single repository? Heck, even a
single project raises issues if you have more than one codeline. What
does the alias tell you? Can you give us a concrete example of how you
would use the alias in a specific context?
--
David
________________________________
From: OS [mailto:os@portfoolio.com]
Sent: Wednesday, February 20, 2008 1:18 PM
To: Reedick, Andrew
Cc: users@subversion.tigris.org
Subject: Re: feature request: svn revision alias
It's (a) -- "a way to alias a REV number".
As I said, call it revision aliasing or revision
naming.
svn alias/revalias/revname <rev> <name>
(or svn alias/revalias/revname -r <rev> <name>,
whatever is more consistent)
The effect would be that wherever I'm able to
use a revision number today
I would be able to use a revision name/alias.
Reedick, Andrew wrote:
From: OS [mailto:os@portfoolio.com]
Sent: Tuesday, February 19, 2008 2:11 PM
To: Paul Koning
Cc: users@subversion.tigris.org
Subject: Re: feature request: svn
revision alias
Yes:
Look, svn-people, all I was suggesting
was a practical, simple (I
thought) solution to a
common, simple problem. It's something
that all other SCMs offer and
it would appease
many people used to that type of
procedure (I think).
As far I can see, all the machinery is
already there. The only thing
missing is the symbolic name.
Don't even call it tagging. svn promotes
tag-via-copy, fine. Call it
revision naming or aliasing,
whatever. And let the users use it as
they see fit. Or not. It would
be an option that wouldn't
bother anyone not using it.
*Grrrrrr* You haven't sufficiently
defined what you're asking for. Is
it:
a) a way to alias a REV number
in the same manner as HEAD, PREV,
etc., or
b) to implement a more
traditional style of tagging/labeling
instead of using 'svn copy', or
c) a way to 'tag' single files
(or revisions) in order to see
what tag directories the
version/revision is in, or
d) something else?
e) an easier way to query/search
on revision properties
If it's 'a', then I ask what's the
benefit? A revision refers to the
entire repository, or to the actual file
changes made in that single
revision. A revision/alias
simultaneously provides too much and too
little information to be useful in most
cases. A revision alias could
be useful for marking merge points, or
promoted/tested revisions, and
would probably be less clumsy than using
revision properties. Which
implies that an easier way to query or
search on revision properties is
what you're really after? Ex:
svn co -r prop:TESTED
svn://some/where/foo.java
Which actually sounds like a really good
idea, IMO. Let's call that
option 'e'.
*****
The information transmitted is intended
only for the person or entity to which it is addressed and may contain
confidential, proprietary, and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking of any action
in reliance upon this information by persons or entities other than the
intended recipient is prohibited. If you received this in error, please
contact the sender and delete the material from all computers. GA623
************************************************************************
*
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.
************************************************************************
*
Re: feature request: svn revision alias
Posted by OS <os...@portfoolio.com>.
I did (in fact, Paul Koning did):
>I don't think of a tag that way. Instead, I view it as a name for a
>point in the history of my code.
>
>So one day I may say "I'd like to see the code for "ls" as it was in
>the baselevel tagged "V3.14_baselevel3" and another day I may go
>looking for the code of another piece with that same tag.
>
>To do that, I'd ask Subversion for the subtree in question as it was
>in that rev. Right now I'd use a numeric rev; with aliases I could
>use a named rev.
>
Bicking, David (HHoldings, IT) wrote:
> First, can you find a way to send your posts in ASCII? My Outlook
> insists on top-posting these unless I convert to text, which produces
> the bizarre formatting seen in Andrew Reedick's reply (and I chose not
> to do that this time around).
>
> Second, you did not answer the question that comes with option (a):
> what is the benefit? How would you name such a revision if you
> maintain multiple projects in a single repository? Heck, even a single
> project raises issues if you have more than one codeline. What does
> the alias tell you? Can you give us a concrete example of how you
> would use the alias in a specific context?
>
> --
> David
>
> ------------------------------------------------------------------------
> *From:* OS [mailto:os@portfoolio.com]
> *Sent:* Wednesday, February 20, 2008 1:18 PM
> *To:* Reedick, Andrew
> *Cc:* users@subversion.tigris.org
> *Subject:* Re: feature request: svn revision alias
>
> It's (a) -- "a way to alias a REV number".
> As I said, call it revision aliasing or revision naming.
>
> svn alias/revalias/revname <rev> <name>
> (or svn alias/revalias/revname -r <rev> <name>, whatever is more
> consistent)
>
> The effect would be that wherever I'm able to use a revision
> number today
> I would be able to use a revision name/alias.
>
>
> Reedick, Andrew wrote:
>
>>>From: OS [mailto:os@portfoolio.com]
>>>Sent: Tuesday, February 19, 2008 2:11 PM
>>>To: Paul Koning
>>>Cc: users@subversion.tigris.org
>>>Subject: Re: feature request: svn revision alias
>>>
>>>Yes:
>>>
>>>Look, svn-people, all I was suggesting was a practical, simple (I
>>>
>>>
>>thought) solution to a
>>
>>
>>>common, simple problem. It's something that all other SCMs offer and
>>>
>>>
>>it would appease
>>
>>
>>>many people used to that type of procedure (I think).
>>>
>>>As far I can see, all the machinery is already there. The only thing
>>>
>>>
>>missing is the symbolic name.
>>
>>
>>>Don't even call it tagging. svn promotes tag-via-copy, fine. Call it
>>>
>>>
>>revision naming or aliasing,
>>
>>
>>>whatever. And let the users use it as they see fit. Or not. It would
>>>
>>>
>>be an option that wouldn't
>>
>>
>>>bother anyone not using it.
>>>
>>>
>>
>>
>>*Grrrrrr* You haven't sufficiently defined what you're asking for. Is
>>it:
>> a) a way to alias a REV number in the same manner as HEAD, PREV,
>>etc., or
>> b) to implement a more traditional style of tagging/labeling
>>instead of using 'svn copy', or
>> c) a way to 'tag' single files (or revisions) in order to see
>>what tag directories the version/revision is in, or
>> d) something else?
>> e) an easier way to query/search on revision properties
>>
>>If it's 'a', then I ask what's the benefit? A revision refers to the
>>entire repository, or to the actual file changes made in that single
>>revision. A revision/alias simultaneously provides too much and too
>>little information to be useful in most cases. A revision alias could
>>be useful for marking merge points, or promoted/tested revisions, and
>>would probably be less clumsy than using revision properties. Which
>>implies that an easier way to query or search on revision properties is
>>what you're really after? Ex:
>> svn co -r prop:TESTED svn://some/where/foo.java
>>Which actually sounds like a really good idea, IMO. Let's call that
>>option 'e'.
>>
>>
>>*****
>>
>>The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623
>>
>>
>>
>>
>>
>>
>>
>
>
> *************************************************************************
> 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.
> *************************************************************************
RE: Re: feature request: svn revision alias
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
First, can you find a way to send your posts in ASCII? My Outlook
insists on top-posting these unless I convert to text, which produces
the bizarre formatting seen in Andrew Reedick's reply (and I chose not
to do that this time around).
Second, you did not answer the question that comes with option (a): what
is the benefit? How would you name such a revision if you maintain
multiple projects in a single repository? Heck, even a single project
raises issues if you have more than one codeline. What does the alias
tell you? Can you give us a concrete example of how you would use the
alias in a specific context?
--
David
________________________________
From: OS [mailto:os@portfoolio.com]
Sent: Wednesday, February 20, 2008 1:18 PM
To: Reedick, Andrew
Cc: users@subversion.tigris.org
Subject: Re: feature request: svn revision alias
It's (a) -- "a way to alias a REV number".
As I said, call it revision aliasing or revision naming.
svn alias/revalias/revname <rev> <name>
(or svn alias/revalias/revname -r <rev> <name>, whatever is more
consistent)
The effect would be that wherever I'm able to use a revision
number today
I would be able to use a revision name/alias.
Reedick, Andrew wrote:
From: OS [mailto:os@portfoolio.com]
Sent: Tuesday, February 19, 2008 2:11 PM
To: Paul Koning
Cc: users@subversion.tigris.org
Subject: Re: feature request: svn revision alias
Yes:
Look, svn-people, all I was suggesting was a
practical, simple (I
thought) solution to a
common, simple problem. It's something that all
other SCMs offer and
it would appease
many people used to that type of procedure (I
think).
As far I can see, all the machinery is already
there. The only thing
missing is the symbolic name.
Don't even call it tagging. svn promotes
tag-via-copy, fine. Call it
revision naming or aliasing,
whatever. And let the users use it as they see
fit. Or not. It would
be an option that wouldn't
bother anyone not using it.
*Grrrrrr* You haven't sufficiently defined what you're
asking for. Is
it:
a) a way to alias a REV number in the same
manner as HEAD, PREV,
etc., or
b) to implement a more traditional style of
tagging/labeling
instead of using 'svn copy', or
c) a way to 'tag' single files (or revisions) in
order to see
what tag directories the version/revision is in, or
d) something else?
e) an easier way to query/search on revision
properties
If it's 'a', then I ask what's the benefit? A revision
refers to the
entire repository, or to the actual file changes made in
that single
revision. A revision/alias simultaneously provides too
much and too
little information to be useful in most cases. A
revision alias could
be useful for marking merge points, or promoted/tested
revisions, and
would probably be less clumsy than using revision
properties. Which
implies that an easier way to query or search on
revision properties is
what you're really after? Ex:
svn co -r prop:TESTED svn://some/where/foo.java
Which actually sounds like a really good idea, IMO.
Let's call that
option 'e'.
*****
The information transmitted is intended only for the
person or entity to which it is addressed and may contain confidential,
proprietary, and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you received this in error, please contact
the sender and delete the material from all computers. GA623
*************************************************************************
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.
*************************************************************************
Re: feature request: svn revision alias
Posted by OS <os...@portfoolio.com>.
It's (a) -- "a way to alias a REV number".
As I said, call it revision aliasing or revision naming.
svn alias/revalias/revname <rev> <name>
(or svn alias/revalias/revname -r <rev> <name>, whatever is more consistent)
The effect would be that wherever I'm able to use a revision number today
I would be able to use a revision name/alias.
Reedick, Andrew wrote:
>>From: OS [mailto:os@portfoolio.com]
>>Sent: Tuesday, February 19, 2008 2:11 PM
>>To: Paul Koning
>>Cc: users@subversion.tigris.org
>>Subject: Re: feature request: svn revision alias
>>
>>Yes:
>>
>>Look, svn-people, all I was suggesting was a practical, simple (I
>>
>>
>thought) solution to a
>
>
>>common, simple problem. It's something that all other SCMs offer and
>>
>>
>it would appease
>
>
>>many people used to that type of procedure (I think).
>>
>>As far I can see, all the machinery is already there. The only thing
>>
>>
>missing is the symbolic name.
>
>
>>Don't even call it tagging. svn promotes tag-via-copy, fine. Call it
>>
>>
>revision naming or aliasing,
>
>
>>whatever. And let the users use it as they see fit. Or not. It would
>>
>>
>be an option that wouldn't
>
>
>>bother anyone not using it.
>>
>>
>
>
>*Grrrrrr* You haven't sufficiently defined what you're asking for. Is
>it:
> a) a way to alias a REV number in the same manner as HEAD, PREV,
>etc., or
> b) to implement a more traditional style of tagging/labeling
>instead of using 'svn copy', or
> c) a way to 'tag' single files (or revisions) in order to see
>what tag directories the version/revision is in, or
> d) something else?
> e) an easier way to query/search on revision properties
>
>If it's 'a', then I ask what's the benefit? A revision refers to the
>entire repository, or to the actual file changes made in that single
>revision. A revision/alias simultaneously provides too much and too
>little information to be useful in most cases. A revision alias could
>be useful for marking merge points, or promoted/tested revisions, and
>would probably be less clumsy than using revision properties. Which
>implies that an easier way to query or search on revision properties is
>what you're really after? Ex:
> svn co -r prop:TESTED svn://some/where/foo.java
>Which actually sounds like a really good idea, IMO. Let's call that
>option 'e'.
>
>
>*****
>
>The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623
>
>
>
>
>
>
>
RE: Re: feature request: svn revision alias
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> From: OS [mailto:os@portfoolio.com]
> Sent: Tuesday, February 19, 2008 2:11 PM
> To: Paul Koning
> Cc: users@subversion.tigris.org
> Subject: Re: feature request: svn revision alias
>
> Yes:
>
> Look, svn-people, all I was suggesting was a practical, simple (I
thought) solution to a
> common, simple problem. It's something that all other SCMs offer and
it would appease
> many people used to that type of procedure (I think).
>
> As far I can see, all the machinery is already there. The only thing
missing is the symbolic name.
>
> Don't even call it tagging. svn promotes tag-via-copy, fine. Call it
revision naming or aliasing,
> whatever. And let the users use it as they see fit. Or not. It would
be an option that wouldn't
> bother anyone not using it.
*Grrrrrr* You haven't sufficiently defined what you're asking for. Is
it:
a) a way to alias a REV number in the same manner as HEAD, PREV,
etc., or
b) to implement a more traditional style of tagging/labeling
instead of using 'svn copy', or
c) a way to 'tag' single files (or revisions) in order to see
what tag directories the version/revision is in, or
d) something else?
e) an easier way to query/search on revision properties
If it's 'a', then I ask what's the benefit? A revision refers to the
entire repository, or to the actual file changes made in that single
revision. A revision/alias simultaneously provides too much and too
little information to be useful in most cases. A revision alias could
be useful for marking merge points, or promoted/tested revisions, and
would probably be less clumsy than using revision properties. Which
implies that an easier way to query or search on revision properties is
what you're really after? Ex:
svn co -r prop:TESTED svn://some/where/foo.java
Which actually sounds like a really good idea, IMO. Let's call that
option 'e'.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: feature request: svn revision alias
Posted by OS <os...@portfoolio.com>.
Yes:
>I don't think of a tag that way. Instead, I view it as a name for a
>point in the history of my code.
>
>So one day I may say "I'd like to see the code for "ls" as it was in
>the baselevel tagged "V3.14_baselevel3" and another day I may go
>looking for the code of another piece with that same tag.
>
>To do that, I'd ask Subversion for the subtree in question as it was
>in that rev. Right now I'd use a numeric rev; with aliases I could
>use a named rev.
>
Look, svn-people, all I was suggesting was a practical, simple (I
thought) solution to a
common, simple problem. It's something that all other SCMs offer and it
would appease
many people used to that type of procedure (I think).
As far I can see, all the machinery is already there. The only thing
missing is the symbolic name.
Don't even call it tagging. svn promotes tag-via-copy, fine. Call it
revision naming or aliasing,
whatever. And let the users use it as they see fit. Or not. It would be
an option that wouldn't
bother anyone not using it.
Peace :)
Paul Koning wrote:
>>>>>>"Andrew" == Andrew Reedick <Reedick> writes:
>>>>>>
>>>>>>
>
> >> -----Original Message----- From: Paul Koning
> >> In Subversion, a revision number always identifies a revision of
> >> the repository. The WHOLE repository.
> >>
> >> Any one checkin is likely to change only a subset of the
> >> repository, but nevertheless the rev number identifies a
> >> particular state of the whole repository. If you care what bits
> >> were changed by a particular rev, do "svn log -r 1234 -v" on the
> >> repository root, and svn will tell you.
>
> Andrew> That's my point. The revision number applies to the WHOLE
> Andrew> repository. The Humans use tags to baseline a SUBSET of the
> Andrew> repository. A revision number by itself is useless for that
> Andrew> purpose.
>
> >> So the proposal certainly is logically valid.
>
> Andrew> The OP's proposal is: The svn revision is pretty much
> Andrew> equivalent to what a tag is in other systems. svn alias
> Andrew> <rev> <name> (or svn revalias <rev> <name>)
>
> Andrew> In any system, a tag is a subset of a repository, normally
> Andrew> used to create a baseline. (That's the definition I'm
> Andrew> working under.)
>
>Ok, now I see the problem. Maybe it comes from thinking in CVS, where
>there is no real repository, just a large number of basically
>unrelated files each with its own history and tags.
>
>I don't think of a tag that way. Instead, I view it as a name for a
>point in the history of my code.
>
>So one day I may say "I'd like to see the code for "ls" as it was in
>the baselevel tagged "V3.14_baselevel3" and another day I may go
>looking for the code of another piece with that same tag.
>
>To do that, I'd ask Subversion for the subtree in question as it was
>in that rev. Right now I'd use a numeric rev; with aliases I could
>use a named rev.
>
>Either way, I think of the repository as a 3D file system: the usual
>two dimensions of the name space tree, plus a time dimension. A rev
>and a tag is just a label of a particular value of the time dimension
>-- a plane of the 3D space -- and I can see any part of that plane --
>any subtree in the file system as of that point in time.
>
> paul
>
>
>
>
>
>
>
RE: feature request: svn revision alias
Posted by Paul Koning <Pa...@dell.com>.
>>>>> "Andrew" == Andrew Reedick <Reedick> writes:
>> -----Original Message----- From: Paul Koning
>> In Subversion, a revision number always identifies a revision of
>> the repository. The WHOLE repository.
>>
>> Any one checkin is likely to change only a subset of the
>> repository, but nevertheless the rev number identifies a
>> particular state of the whole repository. If you care what bits
>> were changed by a particular rev, do "svn log -r 1234 -v" on the
>> repository root, and svn will tell you.
Andrew> That's my point. The revision number applies to the WHOLE
Andrew> repository. The Humans use tags to baseline a SUBSET of the
Andrew> repository. A revision number by itself is useless for that
Andrew> purpose.
>> So the proposal certainly is logically valid.
Andrew> The OP's proposal is: The svn revision is pretty much
Andrew> equivalent to what a tag is in other systems. svn alias
Andrew> <rev> <name> (or svn revalias <rev> <name>)
Andrew> In any system, a tag is a subset of a repository, normally
Andrew> used to create a baseline. (That's the definition I'm
Andrew> working under.)
Ok, now I see the problem. Maybe it comes from thinking in CVS, where
there is no real repository, just a large number of basically
unrelated files each with its own history and tags.
I don't think of a tag that way. Instead, I view it as a name for a
point in the history of my code.
So one day I may say "I'd like to see the code for "ls" as it was in
the baselevel tagged "V3.14_baselevel3" and another day I may go
looking for the code of another piece with that same tag.
To do that, I'd ask Subversion for the subtree in question as it was
in that rev. Right now I'd use a numeric rev; with aliases I could
use a named rev.
Either way, I think of the repository as a 3D file system: the usual
two dimensions of the name space tree, plus a time dimension. A rev
and a tag is just a label of a particular value of the time dimension
-- a plane of the 3D space -- and I can see any part of that plane --
any subtree in the file system as of that point in time.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning@Dell.com]
> Sent: Tuesday, February 19, 2008 10:30 AM
> To: Reedick, Andrew
> Cc: os@portfoolio.com; users@subversion.tigris.org
> Subject: RE: feature request: svn revision alias
>
>
>
> In Subversion, a revision number always identifies a revision of the
> repository. The WHOLE repository.
>
> Any one checkin is likely to change only a subset of the repository,
> but nevertheless the rev number identifies a particular state of the
> whole repository. If you care what bits were changed by a particular
> rev, do "svn log -r 1234 -v" on the repository root, and svn will tell
> you.
That's my point. The revision number applies to the WHOLE repository.
The Humans use tags to baseline a SUBSET of the repository. A revision
number by itself is useless for that purpose.
> So the proposal certainly is logically valid.
The OP's proposal is:
The svn revision is pretty much equivalent to what a tag is in
other systems.
svn alias <rev> <name> (or svn revalias <rev> <name>)
In any system, a tag is a subset of a repository, normally used to
create a baseline. (That's the definition I'm working under.) The
alias is a single rev. A single rev is useless for marking subsets of
repositories.[1] Therefore, 'svn alias' is useless as a substitute for
tags and thus useless for creating baselines, and thus useless to the
OP's stated purpose.[2]
> And I could see some
> uses for it -- some of the things done with tags are more conveniently
> done by rev aliases than by lightweight copy (though they can be made
> to work either way. For example, we tag the most recent rev in the
> version Xyz development stream for which the nightly build procedure
> ran without errors. In CVS (and presumably with the alias scheme)
> that's just a tag operation. In Subversion, it requires deleting the
> old tag, then making a new one. For various reasons, that isn't as
> good a solution (though it is good enough to get the job done).
In this case, the tag is applied to a whole mess of files, normally an
entire subtree. Aliasing a single SVN revision would only 'tag' the few
files in the revision. 'svn copy ... /tags/...' will "tag" many
revisions.
The proposed 'svn alias <rev> <name>' would create another HEAD, PREV,
etc. type label. If I told you I want the HEAD, what code would you
give me? You would give me the three or four files that were checked in
last, instead of the thousands of files in the rel.1.0.0 baseline.
Also, 'svn alias <rev> <name>' is very similar to SVN properties. Would
you rather use 'svn copy' or 'svn propset' to create a baseline/tag in
SVN?
Also^2, in other systems, you can tag a single file. How would 'svn
alias <rev> <name>' work on a single file when revisions contain several
files?
A useful 'svn alias' command would have to be something like:
svn alias -r REV <alias> <svn:url | svn_path>
which is essentially the same thing as a 'svn copy' tag or a 'svn
propset' tag.
[1] Yes, a rev is a very, very, very, very small subset of a repository.
But how often do you tag/baseline using a single revision?
[2] Unless I've completely missed the point despite re-reading the OP's
email a few times. =/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by Paul Koning <Pa...@dell.com>.
>>>>> "Andrew" == Andrew Reedick <Reedick> writes:
>> Wouldn't this be useful: svn alias <rev> <name> (or svn revalias
>> <rev> <name>)
>>
>> Then one would be able to use <rev> and <name> interchangeably in
>> other
>> svn operations. Call it the poor man's svn tag! :)
Andrew> In SVN, an alias or revision number by itself is useless.
Andrew> You need a dir to go along with the revision/alias to be
Andrew> accurate. Aliasing 'FOO' to a revision in a repository
Andrew> doesn't tell me a damn thing. What code does FOO (or
Andrew> revision 1234) apply to? A revision can have check-ins from
Andrew> multiple directories _across_ multiple baselines. Even if
Andrew> FOO is from a check-in under one tree, does FOO apply to the
Andrew> root of the tree, or just for a subproject?
Andrew> Ex: I check-in /branches/rel.1.0/big_project/logging/log.java
Andrew> as revision 1234. I alias 1234 as FOO. Does FOO apply to
Andrew> 'rel1.0', 'big_project', or just the 'logging' component?
I must be missing something.
In Subversion, a revision number always identifies a revision of the
repository. The WHOLE repository.
Any one checkin is likely to change only a subset of the repository,
but nevertheless the rev number identifies a particular state of the
whole repository. If you care what bits were changed by a particular
rev, do "svn log -r 1234 -v" on the repository root, and svn will tell
you.
So the proposal certainly is logically valid. And I could see some
uses for it -- some of the things done with tags are more conveniently
done by rev aliases than by lightweight copy (though they can be made
to work either way. For example, we tag the most recent rev in the
version Xyz development stream for which the nightly build procedure
ran without errors. In CVS (and presumably with the alias scheme)
that's just a tag operation. In Subversion, it requires deleting the
old tag, then making a new one. For various reasons, that isn't as
good a solution (though it is good enough to get the job done).
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: OS [mailto:os@portfoolio.com]
> Sent: Monday, February 18, 2008 12:19 AM
> To: users@subversion.tigris.org
> Subject: feature request: svn revision alias
>
> And that made me think whether it would be difficult to implement that
> in svn natively.
>
> The svn revision is pretty much equivalent to what a tag is in other
> systems.
> But it's a numeric value, hard to remember, etc -- and people wish to
> give tags descriptive names.
>
> Wouldn't this be useful:
> svn alias <rev> <name> (or svn revalias <rev> <name>)
>
> Then one would be able to use <rev> and <name> interchangeably in
other
> svn operations.
> Call it the poor man's svn tag! :)
That's about as useful as putting license plates on the rear bumpers of
airplanes. =)
In SVN, an alias or revision number by itself is useless. You need a
dir to go along with the revision/alias to be accurate. Aliasing 'FOO'
to a revision in a repository doesn't tell me a damn thing. What code
does FOO (or revision 1234) apply to? A revision can have check-ins
from multiple directories _across_ multiple baselines. Even if FOO is
from a check-in under one tree, does FOO apply to the root of the tree,
or just for a subproject?
Ex:
I check-in /branches/rel.1.0/big_project/logging/log.java as
revision 1234. I alias 1234 as FOO. Does FOO apply to 'rel1.0',
'big_project', or just the 'logging' component?
Ex #2:
I fix a logging bug and merged the code fix across three
branches as revision 1234:
/branches/prod.1.0.1/logging/log.java
/branches/rel.1.1.0/logging/log.java
/branches/rel.2.0/logging/log.java
What does revision 1234 or FOO actually represent?
../tags/some_dir clearly establishes a baseline. The tags/some_dir
eliminates the need to remember a random revision number, which is what
you're asking for.
Ex:
svn copy /branches/rel.1.0/big_project/logging /tags/logging.1.1
SVN already does what your users want to do.
I went from seven years of ClearCase before using SVN. Initially, I had
a bear of time with the idea of one and only one revision number, no
traditional revision tree, and the lack of traditional labels/tags.
Nowadays, I don't miss any of those things. And more importantly, I can
see how the old RCS paradigm has really limited systems like ClearCase,
Dimensions, CVS, etc., which do implement "traditional" tags/labels.
Your users need to get used to the (large) paradigm shifts in SVN.
(Except for the (criminal) lack of merge tracking and merge bugs,) I've
found that SVN is a great system based on solid paradigms. SVN works,
but SVN will not work if you try to force it to do things the way you
did in the old country. Which is why you put tail numbers and
transponders on airplanes instead of license plates mounted on rear
bumpers.
Lecturing aside, the purpose of a tag is to create a baseline. 'svn
copy' is how you create a tag/baseline in SVN. Instead of placing tags
or labels on files, you simply create a directory (normally under
.../tags) of the versions you want, and that directory becomes a
tag/baseline. It's a simple concept, but for some reason, people are so
used to the paradigm of applying tags "in-place" to existing files that
creating a tag directory is somehow "complicated."
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: feature request: svn revision alias
Posted by Karl Fogel <kf...@red-bean.com>.
"Reedick, Andrew" <jr...@ATT.COM> writes:
> "what tags apply to this file?" is the same as asking what baselines
> (aka tags) is the file in. In SVN you can search the baselines (tag
> directories) for the file, or you use merging to make sure the file gets
> into the various baselines/tags in the first place.
>
> Granted, searching over a whole bunch of SVN tag directories isn't as
> efficient as looking at the tags on an individual file. However, the
> whole reason we've been able to do that in other RCS like systems, is
> because RCS stored all information about a file on a per file basis,
> which made it grossly inefficient to manipulate groups of files or to
> think about all the files as a whole.
What you say is true, but still it would be nice if people had an
efficient way to ask "What tags is this particular version of this
file in?" The fact that Subversion doesn't offer a clean way to do
this is a deficiency that we should rectify someday, IMHO. Just
because we version trees doesn't mean we should forget about files :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: feature request: svn revision alias
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Miller, Eric [mailto:Eric.Miller@amd.com]
> Sent: Tuesday, February 19, 2008 10:29 AM
> To: Karl Fogel; OS
> Cc: users@subversion.tigris.org
> Subject: RE: feature request: svn revision alias
>
>
> Of course copies-as-tags fails in the "what tags apply to this file?"
> scenario.
Bzzzt! Not applicable due to paradigm shift and/or bad assumptions from
using RCS based systems for so long. =)
"what tags apply to this file?" is the same as asking what baselines
(aka tags) is the file in. In SVN you can search the baselines (tag
directories) for the file, or you use merging to make sure the file gets
into the various baselines/tags in the first place.
Granted, searching over a whole bunch of SVN tag directories isn't as
efficient as looking at the tags on an individual file. However, the
whole reason we've been able to do that in other RCS like systems, is
because RCS stored all information about a file on a per file basis,
which made it grossly inefficient to manipulate groups of files or to
think about all the files as a whole.
In other words, SVN encourages you to think in terms of change-sets and
baselines. RCS-based systems encourage you to think in terms of
individual files. SVN == forest. ClearCase/RCS/CVS == trees.
IMHO, thinking in terms of change-sets and baselines is better from a
process/change management/software life cycle point of view.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: feature request: svn revision alias
Posted by "Gleason, Todd" <tg...@impac.com>.
Isn't this where you'd use revision graphs? TortoiseSVN has this
built-in, and on the command line you can use
http://svn.collab.net/repos/svn/trunk/tools/client-side/svn-graph.pl
Admittedly, revision graphs are dog slow, but I don't imagine needing
this feature very often either.
-----Original Message-----
From: Miller, Eric [mailto:Eric.Miller@amd.com]
Sent: Tuesday, February 19, 2008 8:29 AM
To: Karl Fogel; OS
Cc: users@subversion.tigris.org
Subject: RE: feature request: svn revision alias
Of course copies-as-tags fails in the "what tags apply to this file?"
scenario.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: feature request: svn revision alias
Posted by Ni...@infineon.com.
> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning@dell.com]
>
> Consider the example I gave: a tag "last_good_build_x".
>
> If I look at the repository, I see the most recent good
> build, tagged with that tag.
>
> But if I want to know "what were the earlier good builds",
> the intuitive answer would be "look at the history of that
> tag". But that history doesn't exist in Subversion, at least
> not in something directly accessible rather than data to be
> laboriously extracted from a much larger log.
>
> In other words, if I want to know "what were all the things (all the
> revisions) tagged X" that's not a question that Subversion can answer.
>
> paul
Wouldn't it be possible (maybe even preferable?) to use a rev property
for this? Then you could see all good builds by looking in the rev logs.
Presumably a "grep" and a "tail" would show you the latest good build.
Since a property is a name/value pair, you could have a QA property with
various settings, describing the state of this revision and even change
it based on the level of testing that rev has received.
Usually, naming/aliasing revisions is something you do that adds meaning
to a revision, but this is probably better expressed in metadata (or
properties in SVN).
The obvious downside to properties, is that there are usualyy not
clearly expressed in GUI version trees.
Nick.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by Paul Koning <Pa...@dell.com>.
>>>>> "David" == David Bicking <Bicking> writes:
>> -----Original Message----- From: Paul Koning
>> [mailto:Paul_Koning@dell.com]
>> ...
>> So we end up with this:
>>
>> svn rm .../tags/last_good_nightly_x svn cp .../branches/x
>> .../tags/last_good_nightly_x
>>
>> and that works.
David> Why is this a problem - because it is a two-step process?
Mostly because it's a cause of user confusion -- the command does
different things depending on the previous state of the repository.
>> Next problem: I want to see the history of that tag. In other
>> words, what are all the revs that I tagged?
>>
>> The obvious answer is:
>>
>> svn log .../tags/last_good_nightly_x
>>
>> but that doesn't give me the history of the tag (the sequence of
>> revs that were tagged with that tag); instead, it gives me the
>> history of the branch rev that was most recently tagged, or it
>> just gives me the last tag (if I say --stop-on-copy).
David> What is your use case for this feature? What is the benefit
David> of "changing the contents" of a tag, and tracking the history
David> of those changes? Is "the sequence of revs having that tag" a
David> history of what revision numbers that name referenced in the
David> past (e.g., r22 on Monday, r43 on Tuesday, r55 on Friday)? Is
David> this and the prior point essentially a pining for "floating
David> labels"?
Consider the example I gave: a tag "last_good_build_x".
If I look at the repository, I see the most recent good build, tagged
with that tag.
But if I want to know "what were the earlier good builds", the
intuitive answer would be "look at the history of that tag". But that
history doesn't exist in Subversion, at least not in something
directly accessible rather than data to be laboriously extracted from
a much larger log.
In other words, if I want to know "what were all the things (all the
revisions) tagged X" that's not a question that Subversion can answer.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: feature request: svn revision alias
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 19, 2008, at 14:42, kmradke@rockwellcollins.com wrote:
>>> In our build scripts we want to tag "last good nightly build
>>> of release stream x". So, roughly speaking, that amounts to:
>>>
>>> svn cp .../branches/x .../tags/last_good_nightly_x
>>>
>>> However, that doesn't work. More precisely, it only works
>>> the first time. If you do it a second time, you end up with
>>> "x" as a subdirectory inside last_good_nightly_x, because the
>>> second time is't a copy to an existing directory name rather
>>> than a nonexistent directory name.
>>>
>>> So we end up with this:
>>>
>>> svn rm .../tags/last_good_nightly_x
>>> svn cp .../branches/x .../tags/last_good_nightly_x
>>>
>>> and that works.
>>
>> Why is this a problem - because it is a two-step process?
>
> Personally, I think it would be nice to have a '-f' option
> to force an overwrite, thus reducing the 2 steps into one.
> (Just like the unix cp -f)
>
> svn cp -f .../branches/x .../tags/last_good_nightly_x
I believe you can already use the Multiple URL Command Client,
svnmucc, to perform these two steps in a single revision.
http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmucc/
svnmucc.c
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by km...@rockwellcollins.com.
"Bicking, David (HHoldings, IT)" <Da...@thehartford.com> wrote on
02/19/2008 02:33:51 PM:
> > -----Original Message-----
> > From: Paul Koning [mailto:Paul_Koning@dell.com]
> >
> > >> Aside from "some people aren't used to it", I've not seen
> > any >> convincing disadvantages demonstrated for just using
> > 'svn copy' to >> create a tag, I have to admit. I'm keeping
> > an open mind, but if >> we're going to extend Subversion's
> > interface, it should be because >> of a convincing advantage.
> >
> > Ok, here's one.
> >
> > In our build scripts we want to tag "last good nightly build
> > of release stream x". So, roughly speaking, that amounts to:
> >
> > svn cp .../branches/x .../tags/last_good_nightly_x
> >
> > However, that doesn't work. More precisely, it only works
> > the first time. If you do it a second time, you end up with
> > "x" as a subdirectory inside last_good_nightly_x, because the
> > second time is't a copy to an existing directory name rather
> > than a nonexistent directory name.
> >
> > So we end up with this:
> >
> > svn rm .../tags/last_good_nightly_x
> > svn cp .../branches/x .../tags/last_good_nightly_x
> >
> > and that works.
>
> Why is this a problem - because it is a two-step process?
Personally, I think it would be nice to have a '-f' option
to force an overwrite, thus reducing the 2 steps into one.
(Just like the unix cp -f)
svn cp -f .../branches/x .../tags/last_good_nightly_x
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning@dell.com]
>
> >> Aside from "some people aren't used to it", I've not seen
> any >> convincing disadvantages demonstrated for just using
> 'svn copy' to >> create a tag, I have to admit. I'm keeping
> an open mind, but if >> we're going to extend Subversion's
> interface, it should be because >> of a convincing advantage.
>
> Ok, here's one.
>
> In our build scripts we want to tag "last good nightly build
> of release stream x". So, roughly speaking, that amounts to:
>
> svn cp .../branches/x .../tags/last_good_nightly_x
>
> However, that doesn't work. More precisely, it only works
> the first time. If you do it a second time, you end up with
> "x" as a subdirectory inside last_good_nightly_x, because the
> second time is't a copy to an existing directory name rather
> than a nonexistent directory name.
>
> So we end up with this:
>
> svn rm .../tags/last_good_nightly_x
> svn cp .../branches/x .../tags/last_good_nightly_x
>
> and that works.
Why is this a problem - because it is a two-step process?
>
> Next problem: I want to see the history of that tag. In
> other words, what are all the revs that I tagged?
>
> The obvious answer is:
>
> svn log .../tags/last_good_nightly_x
>
> but that doesn't give me the history of the tag (the sequence
> of revs that were tagged with that tag); instead, it gives me
> the history of the branch rev that was most recently tagged,
> or it just gives me the last tag (if I say --stop-on-copy).
What is your use case for this feature? What is the benefit of
"changing the contents" of a tag, and tracking the history of those
changes? Is "the sequence of revs having that tag" a history of what
revision numbers that name referenced in the past (e.g., r22 on Monday,
r43 on Tuesday, r55 on Friday)? Is this and the prior point essentially
a pining for "floating labels"?
--
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: RE: feature request: svn revision alias
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning@dell.com]
> Sent: Tuesday, February 19, 2008 10:38 AM
> To: Eric.Miller@amd.com
> Cc: kfogel@red-bean.com; os@portfoolio.com;
users@subversion.tigris.org
> Subject: RE: feature request: svn revision alias
>
>
> >> Aside from "some people aren't used to it", I've not seen any
> >> convincing disadvantages demonstrated for just using 'svn copy' to
> >> create a tag, I have to admit. I'm keeping an open mind, but if
> >> we're going to extend Subversion's interface, it should be because
> >> of a convincing advantage.
>
> Ok, here's one.
>
> In our build scripts we want to tag "last good nightly build of
> release stream x". So, roughly speaking, that amounts to:
>
> svn cp .../branches/x .../tags/last_good_nightly_x
>
> However, that doesn't work. More precisely, it only works the first
> time. If you do it a second time, you end up with "x" as a
> subdirectory inside last_good_nightly_x, because the second time is't
> a copy to an existing directory name rather than a nonexistent
> directory name.
The solution is to store the revision number and the path somewhere.
With those two items of data, you can easily reproduce your build and
have easy access to history.
The downside is that such information isn't "easy" to store in
subversion, unless you use properties, or check-in a file containing the
information in a separate admin dir. Which isn't that difficult to
implement, but the fact that you have to implement it yourself is
annoying. =/
>
> So we end up with this:
>
> svn rm .../tags/last_good_nightly_x
> svn cp .../branches/x .../tags/last_good_nightly_x
>
> and that works.
>
> Next problem: I want to see the history of that tag. In other words,
> what are all the revs that I tagged?
If you save off the svn_url+rev for each build, then you can:
svn log -r PREVIOUS_BUILD_REV:CURRENT_BUILD_REV svn_url
"Easy," and free of Evil Peg Revisions(tm) but annoying since you have
to implement it yourself.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by Paul Koning <Pa...@dell.com>.
>> Aside from "some people aren't used to it", I've not seen any
>> convincing disadvantages demonstrated for just using 'svn copy' to
>> create a tag, I have to admit. I'm keeping an open mind, but if
>> we're going to extend Subversion's interface, it should be because
>> of a convincing advantage.
Ok, here's one.
In our build scripts we want to tag "last good nightly build of
release stream x". So, roughly speaking, that amounts to:
svn cp .../branches/x .../tags/last_good_nightly_x
However, that doesn't work. More precisely, it only works the first
time. If you do it a second time, you end up with "x" as a
subdirectory inside last_good_nightly_x, because the second time is't
a copy to an existing directory name rather than a nonexistent
directory name.
So we end up with this:
svn rm .../tags/last_good_nightly_x
svn cp .../branches/x .../tags/last_good_nightly_x
and that works.
Next problem: I want to see the history of that tag. In other words,
what are all the revs that I tagged?
The obvious answer is:
svn log .../tags/last_good_nightly_x
but that doesn't give me the history of the tag (the sequence of revs
that were tagged with that tag); instead, it gives me the history of
the branch rev that was most recently tagged, or it just gives me the
last tag (if I say --stop-on-copy).
So I end up with:
svn log .../tags
and filter the output for references to last_good_nightly_x. Yes,
that works. But the performance is quite bad, and it's a hassle to
program even with friendly tools like pysvn.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: feature request: svn revision alias
Posted by "Miller, Eric" <Er...@amd.com>.
> There have been some requests for this before. It's not out of the
> question, but it's complicated. For example, we already have some
> symbolic revision names ("HEAD", "PREV", etc), and these would have to
> become special reserved labels, since they can already be used where a
> revision number would normally be used. But then we have to predict
> all future special labels, which is hard to do.
>
> Aside from "some people aren't used to it", I've not seen any
> convincing disadvantages demonstrated for just using 'svn copy' to
> create a tag, I have to admit. I'm keeping an open mind, but if we're
> going to extend Subversion's interface, it should be because of a
> convincing advantage.
I swear I saw a dev agree this was a valid use case. I wonder if I can
dig it up...
Of course copies-as-tags fails in the "what tags apply to this file?"
scenario.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: feature request: svn revision alias
Posted by OS <os...@portfoolio.com>.
Reserved revision names? No problem.
The user wouldn't be allowed to create that kind of alias, of course.
(Again, sounds simple?...)
The root of my users' complaint is that tagging is not copying (while
branching is).
As a concept, tagging is just labeling. (I guess?)
And in that sense (and strictly speaking), svn lacks the concept of tagging.
And after looking around, I've found that all other SCMs do support
tagging as a distinct concept.
(I guess they see some advantage in that)
But again, I've given up on "concept" discussions and ended up having to
implement a workaround
at my users' complaints. (It's simple enough thank goodness) The
customer is always right they say :)
So I just thought I'd feed it back as it seemed to fit quite nicely with
svn's revision scheme.
Cheers!
Karl Fogel wrote:
>OS <os...@portfoolio.com> writes:
>
>
>>The svn revision is pretty much equivalent to what a tag is in other
>>systems.
>>But it's a numeric value, hard to remember, etc -- and people wish to
>>give tags descriptive names.
>>
>>
>
>Yes... one way to do that is to give them a name under the 'tags'
>directory... :-)
>
>
>
>>Wouldn't this be useful:
>>svn alias <rev> <name> (or svn revalias <rev> <name>)
>>
>>Then one would be able to use <rev> and <name> interchangeably in
>>other svn operations.
>>Call it the poor man's svn tag! :)
>>
>>I don't know... But it appears simple enough to implement (please
>>excuse my ignorance), and I think
>>many people out there would love this feature. (At least judging by my
>>pesky users!)
>>
>>
>
>There have been some requests for this before. It's not out of the
>question, but it's complicated. For example, we already have some
>symbolic revision names ("HEAD", "PREV", etc), and these would have to
>become special reserved labels, since they can already be used where a
>revision number would normally be used. But then we have to predict
>all future special labels, which is hard to do.
>
>Aside from "some people aren't used to it", I've not seen any
>convincing disadvantages demonstrated for just using 'svn copy' to
>create a tag, I have to admit. I'm keeping an open mind, but if we're
>going to extend Subversion's interface, it should be because of a
>convincing advantage.
>
>-Karl
>
>
>
>
>
RE: Re: feature request: svn revision alias
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> From: tinu44@gmail.com [mailto:tinu44@gmail.com] On Behalf Of
Martin
> Bischoff
> Sent: Tuesday, February 19, 2008 8:03 AM
>
> I can see at least one disadvantage of the way how tags work:
> since a tag is the same as a branch or a copy, it is possible
that users
> commit to a tag (by accident). This means that the tag then no
longer
> represents the same revision as when the tag was created. I'm
sure such a
> situation can easily be corrected, but still, with a distinctive
tag
> operation (named revisions) this might not happen.
>
> Regards.
That is easilly resolved by restricting write access to the "tags" path.
--
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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: feature request: svn revision alias
Posted by "Gleason, Todd" <tg...@impac.com>.
I think the way to solve this is to give only build personnel write
access to the tags folder(s). Then they can create tags, and patch a
tag where appropriate (such as to fix a build error) by merging
developer changes from the trunk.
________________________________
From: tinu44@gmail.com [mailto:tinu44@gmail.com] On Behalf Of Martin
Bischoff
Sent: Tuesday, February 19, 2008 6:03 AM
To: Karl Fogel; users@subversion.tigris.org
Cc: OS
Subject: Re: feature request: svn revision alias
(I'm not (yet) very familiar with subversion, so the following might be
incorrect)
I can see at least one disadvantage of the way how tags work:
since a tag is the same as a branch or a copy, it is possible that users
commit to a tag (by accident). This means that the tag then no longer
represents the same revision as when the tag was created. I'm sure such
a situation can easily be corrected, but still, with a distinctive tag
operation (named revisions) this might not happen.
Regards.
Re: feature request: svn revision alias
Posted by Martin Bischoff <ti...@gmail.com>.
On Mon, Feb 18, 2008 at 5:18 PM, Karl Fogel <kf...@red-bean.com> wrote:
> OS <os...@portfoolio.com> writes:
>
> > Wouldn't this be useful:
> > svn alias <rev> <name> (or svn revalias <rev> <name>)
> >
> > Then one would be able to use <rev> and <name> interchangeably in
> > other svn operations.
> > Call it the poor man's svn tag! :)
> >
>
> Aside from "some people aren't used to it", I've not seen any
> convincing disadvantages demonstrated for just using 'svn copy' to
> create a tag, I have to admit. I'm keeping an open mind, but if we're
> going to extend Subversion's interface, it should be because of a
> convincing advantage.
>
>
(I'm not (yet) very familiar with subversion, so the following might be
incorrect)
I can see at least one disadvantage of the way how tags work:
since a tag is the same as a branch or a copy, it is possible that users
commit to a tag (by accident). This means that the tag then no longer
represents the same revision as when the tag was created. I'm sure such a
situation can easily be corrected, but still, with a distinctive tag
operation (named revisions) this might not happen.
Regards.
Re: feature request: svn revision alias
Posted by Karl Fogel <kf...@red-bean.com>.
OS <os...@portfoolio.com> writes:
> The svn revision is pretty much equivalent to what a tag is in other
> systems.
> But it's a numeric value, hard to remember, etc -- and people wish to
> give tags descriptive names.
Yes... one way to do that is to give them a name under the 'tags'
directory... :-)
> Wouldn't this be useful:
> svn alias <rev> <name> (or svn revalias <rev> <name>)
>
> Then one would be able to use <rev> and <name> interchangeably in
> other svn operations.
> Call it the poor man's svn tag! :)
>
> I don't know... But it appears simple enough to implement (please
> excuse my ignorance), and I think
> many people out there would love this feature. (At least judging by my
> pesky users!)
There have been some requests for this before. It's not out of the
question, but it's complicated. For example, we already have some
symbolic revision names ("HEAD", "PREV", etc), and these would have to
become special reserved labels, since they can already be used where a
revision number would normally be used. But then we have to predict
all future special labels, which is hard to do.
Aside from "some people aren't used to it", I've not seen any
convincing disadvantages demonstrated for just using 'svn copy' to
create a tag, I have to admit. I'm keeping an open mind, but if we're
going to extend Subversion's interface, it should be because of a
convincing advantage.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org