You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Carson <dc...@yahoo.com> on 2009/08/18 22:39:39 UTC
Re: Determining origin of branch
Might I ask why this has never been properly addressed (to my knowledge)?
We have the situation discussed by Derek Mahar where a rename causes the --stop-on-copy option to be short-circuited, such that "svn log ..." alone cannot be used to determine the origin of a branch (without eyeballing it).
Moreover, even in the simple case, to get the information isolated requires "svn log ..." plus some parsing of the output to get what is really of interest, namely URL:revision.
Why not solve both of these issues by simply adding a new command: "svn origin"
1. The new command would return URL:revision, and nothing else. No parsing of the log output necessary.
2. The new command would always return the real origin of the branch, not a copy that might or might not be the original copy.
If #2 is not possible presently, then simply add this information to the repository's schema, so that it is available.
I feel that this particular piece of information is so important, it warrants a new command, or some definitive way of retrieving it. What do others think?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2385021
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Determining origin of branch
Posted by Nathan Nobbe <qu...@gmail.com>.
On Tue, Aug 18, 2009 at 4:39 PM, David Carson <dc...@yahoo.com> wrote:
> Might I ask why this has never been properly addressed (to my knowledge)?
>
> We have the situation discussed by Derek Mahar where a rename causes the
> --stop-on-copy option to be short-circuited, such that "svn log ..." alone
> cannot be used to determine the origin of a branch (without eyeballing it).
>
> Moreover, even in the simple case, to get the information isolated requires
> "svn log ..." plus some parsing of the output to get what is really of
> interest, namely URL:revision.
>
> Why not solve both of these issues by simply adding a new command: "svn
> origin"
>
> 1. The new command would return URL:revision, and nothing else. No parsing
> of the log output necessary.
>
> 2. The new command would always return the real origin of the branch, not a
> copy that might or might not be the original copy.
>
> If #2 is not possible presently, then simply add this information to the
> repository's schema, so that it is available.
>
> I feel that this particular piece of information is so important, it
> warrants a new command, or some definitive way of retrieving it. What do
> others think?
this is why the recommended practice of creating a new branch w/ the same
name as the original branch after reintegration is bad in my mind. svn log
--stop-on-copy is pretty much useless for the first branch w/ the given
name.
i instead create a branch with a new name to avoid the issue in the
reintegration flow.
-nathan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2385750
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: SVN log stops prematurerly
Posted by Bob Archer <bo...@amsi.com>.
> We have a situation where viewing the log of a file suddenly stops at a
> date where we certainly know that the file has existed long before.
>
> Checking out the project at peg revision below where the log stops,
> makes us able to see the previous log.
>
> In TortoiseSVN this last revision in the log is reported as "Replaced",
> what would this mean?
Did you disable the "Stop on copy" option? I think the checkbox is on the bottom of the log viewer dialog.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2408237
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: SVN log stops prematurerly
Posted by Les Mikesell <le...@gmail.com>.
Geir Engebakken wrote:
> We have a situation where viewing the log of a file suddenly stops at a date where we certainly know that the file has existed long before.
>
> Checking out the project at peg revision below where the log stops, makes us able to see the previous log.
>
> In TortoiseSVN this last revision in the log is reported as "Replaced", what would this mean?
>
That should mean that someone deleted the file and added it back - or moved a
different copy on top of it. In the latter case you should see the history of
the replacement file in the log back to earlier dates, though.
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2408217
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
SVN log stops prematurerly
Posted by Geir Engebakken <ge...@edb.com>.
We have a situation where viewing the log of a file suddenly stops at a date where we certainly know that the file has existed long before.
Checking out the project at peg revision below where the log stops, makes us able to see the previous log.
In TortoiseSVN this last revision in the log is reported as "Replaced", what would this mean?
Geir
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2408207
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Re: Determining origin of branch
Posted by David Carson <dc...@yahoo.com>.
> On Aug 18, 2009, at 22:10, David Carson wrote:
>
> >> On Tue, Aug 18, 2009 at 03:39:39PM -0700, David Carson wrote:
> >>
> >>> Why not solve both of these issues by simply adding a new
> >>> command: "svn origin"
> >>>
> >>> 1. The new command would return URL:revision, and nothing else.
> >>> No parsing of the log output necessary.
>
> > All I care about right now is that all copies are done in such a
> > way that retrieving the source of the copy is simple and
> > definitive. This seems quite straightforward. The information is
> > available at the time of the copy, but it is too cumbersome to get
> > to it later, IMHO.
> >
>
>
> Something like what the attached script does?
>
> $ svnorigin.sh http://svn.collab.net/repos/svn/tags/1.6.4
> http://svn.collab.net/repos/svn/branches/1.6.x:38063
> $ svnorigin.sh http://svn.collab.net/repos/svn/branches/1.6.x
> http://svn.collab.net/repos/svn/trunk:35887
> $
Yes, your script attempts to get the information I'm looking for. However, ...
>
> >>> 2. The new command would always return the real origin of the
> >>> branch, not a copy that might or might not be the original copy.
>
> I wasn't sure what you meant by this. Did you mean that, in the above
> example, if you use svnorigin on the 1.6.4 tag, it should say it came
> from trunk?
Your script does not work if the branch was renamed. This is the problem Derek raised. The problem is that the --stop-on-copy option causes the log command to stop the first time it sees a copy. The rename command is a delete followed by a copy.
I suppose this begs the question: Is the rename command the real culprit, and should it be made to behave such that it is distinguished from a regular delete/add series?
However, I don't want to go that deep just now. What I'm saying is, the origin information is basic and extremely valuable. So:
1. It seems prone to error if we all write our own scripts to get at it. (I also wrote a script that works slightly differently.) It should be a built-in command, which gives the core code the ability to change how it gets its information, but this is transparent to the end-user.
2. The origin that is most likely sought is the original copy, not the rename. But, I suppose that could be an option to the command. Namely, I want to see: (a) the latest copy (the rename); (b) I want to see the earliest copy (the branch creation); (c) I want to see all the copies; etc.
Cheers,
David
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2385730
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Determining origin of branch
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Aug 18, 2009, at 22:10, David Carson wrote:
>> On Tue, Aug 18, 2009 at 03:39:39PM -0700, David Carson wrote:
>>
>>> Why not solve both of these issues by simply adding a new
>>> command: "svn origin"
>>>
>>> 1. The new command would return URL:revision, and nothing else.
>>> No parsing of the log output necessary.
> All I care about right now is that all copies are done in such a
> way that retrieving the source of the copy is simple and
> definitive. This seems quite straightforward. The information is
> available at the time of the copy, but it is too cumbersome to get
> to it later, IMHO.
>
Something like what the attached script does?
$ svnorigin.sh http://svn.collab.net/repos/svn/tags/1.6.4
http://svn.collab.net/repos/svn/branches/1.6.x:38063
$ svnorigin.sh http://svn.collab.net/repos/svn/branches/1.6.x
http://svn.collab.net/repos/svn/trunk:35887
$
>>> 2. The new command would always return the real origin of the
>>> branch, not a copy that might or might not be the original copy.
I wasn't sure what you meant by this. Did you mean that, in the above
example, if you use svnorigin on the 1.6.4 tag, it should say it came
from trunk?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2385090
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Re: Determining origin of branch
Posted by David Carson <dc...@yahoo.com>.
> On Tue, Aug 18, 2009 at 03:39:39PM -0700, David Carson wrote:
> > Why not solve both of these issues by simply adding a new command: "svn origin"
> >
> > 1. The new command would return URL:revision, and nothing else. No parsing of the log output necessary.
> >
> > 2. The new command would always return the real origin of the branch, not a copy that might or might not be the original copy.
> >
> > If #2 is not possible presently, then simply add this information to the repository's schema, so that it is available.
> >
> > I feel that this particular piece of information is so important, it warrants a new command, or some definitive way of retrieving it. What do others think?
> >
>
> Ideas like this have been posted many times.
> Some similar ideas of mine (which need much more refinement to be
> useful) are at http://svn.haxx.se/users/archive-2009-02/0729.shtml
> There are probably many more such ideas buried in the archives.
>
Yes, I see how the ideas at this link are somewhat related, but they are much more complicated than what I am suggesting. I would tend to agree that, ideally, branching should be a special case of copying.
> As always the devil is in the details. If you're serious about this
> try to come up with a detailed technical spec for the feature that
> can be discussed. This discussion would involve finding an adequat
> technical solution that *everyone* is happy with. That can take some
> time so make sure to bring patience. You could search the dev@ archives
> for 'svn obliterate' to dig up examples of what is involved in creating
> such a spec and discussing it. (Note that the obliterate discussion
> has been going on for many years so it might be worth searching way
> in the past, too.)
>
All I care about right now is that all copies are done in such a way that retrieving the source of the copy is simple and definitive. This seems quite straightforward. The information is available at the time of the copy, but it is too cumbersome to get to it later, IMHO.
~David
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2385085
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Determining origin of branch
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Aug 18, 2009 at 03:39:39PM -0700, David Carson wrote:
> Might I ask why this has never been properly addressed (to my knowledge)?
>
> We have the situation discussed by Derek Mahar where a rename causes the --stop-on-copy option to be short-circuited, such that "svn log ..." alone cannot be used to determine the origin of a branch (without eyeballing it).
>
> Moreover, even in the simple case, to get the information isolated requires "svn log ..." plus some parsing of the output to get what is really of interest, namely URL:revision.
>
> Why not solve both of these issues by simply adding a new command: "svn origin"
>
> 1. The new command would return URL:revision, and nothing else. No parsing of the log output necessary.
>
> 2. The new command would always return the real origin of the branch, not a copy that might or might not be the original copy.
>
> If #2 is not possible presently, then simply add this information to the repository's schema, so that it is available.
>
> I feel that this particular piece of information is so important, it warrants a new command, or some definitive way of retrieving it. What do others think?
>
Ideas like this have been posted many times.
Some similar ideas of mine (which need much more refinement to be
useful) are at http://svn.haxx.se/users/archive-2009-02/0729.shtml
There are probably many more such ideas buried in the archives.
As always the devil is in the details. If you're serious about this
try to come up with a detailed technical spec for the feature that
can be discussed. This discussion would involve finding an adequat
technical solution that *everyone* is happy with. That can take some
time so make sure to bring patience. You could search the dev@ archives
for 'svn obliterate' to dig up examples of what is involved in creating
such a spec and discussing it. (Note that the obliterate discussion
has been going on for many years so it might be worth searching way
in the past, too.)
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2385029
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].