You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Wolfgang Fritz <wo...@keymile.com> on 2004/09/15 10:37:47 UTC
svn log --stop-on-copy question
Hi,
if I run a
svn log --stop-on-copy
on a directory, it stops on the copy.
If I run the same command on a file in that directory, it does not stop.
(example below). Is that a bug or a feature? I'm running 1.1.0-rc3.
[BTW: the search function of the ML seems to be broken. I never get
results from 2004.]
Wolfgang
bash(86)[branch1]svn log -v --stop-on-copy .
------------------------------------------------------------------------
r49 | (no author) | 2004-09-14 16:07:39 +0200 (Tue, 14 Sep 2004) | 1 line
Changed paths:
M /project1/branches/branch1/Datei1
bla
------------------------------------------------------------------------
r48 | (no author) | 2004-09-14 16:07:05 +0200 (Tue, 14 Sep 2004) | 1 line
Changed paths:
M /project1/branches/branch1/Datei1
bla
------------------------------------------------------------------------
r45 | (no author) | 2004-09-14 15:53:26 +0200 (Tue, 14 Sep 2004) | 1 line
Changed paths:
A /project1/branches/branch1 (from /project1/trunk:1)
A /project1/branches/branch1/Datei1 (from /project1/trunk/Datei1:8)
A /project1/branches/branch1/fdflush.c (from /project1/trunk/fdflush.c:5)
A /project1/branches/branch1/modprobe.c (from
/project1/trunk/modprobe.c:4)
Created branch1
------------------------------------------------------------------------
bash(87)[branch1]svn log -v --stop-on-copy Datei1
------------------------------------------------------------------------
r49 | (no author) | 2004-09-14 16:07:39 +0200 (Tue, 14 Sep 2004) | 1 line
Changed paths:
M /project1/branches/branch1/Datei1
bla
------------------------------------------------------------------------
r48 | (no author) | 2004-09-14 16:07:05 +0200 (Tue, 14 Sep 2004) | 1 line
Changed paths:
M /project1/branches/branch1/Datei1
bla
------------------------------------------------------------------------
r45 | (no author) | 2004-09-14 15:53:26 +0200 (Tue, 14 Sep 2004) | 1 line
Changed paths:
A /project1/branches/branch1 (from /project1/trunk:1)
A /project1/branches/branch1/Datei1 (from /project1/trunk/Datei1:8)
A /project1/branches/branch1/fdflush.c (from /project1/trunk/fdflush.c:5)
A /project1/branches/branch1/modprobe.c (from
/project1/trunk/modprobe.c:4)
Created branch1
------------------------------------------------------------------------
r8 | (no author) | 2004-09-14 12:49:11 +0200 (Tue, 14 Sep 2004) | 1 line
Changed paths:
M /project1/trunk/Datei1
Added another line to Datei1
------------------------------------------------------------------------
r7 | (no author) | 2004-09-14 12:47:01 +0200 (Tue, 14 Sep 2004) | 1 line
Changed paths:
M /project1/trunk/Datei1
Added line to Datei1
------------------------------------------------------------------------
r3 | (no author) | 2004-09-14 12:23:17 +0200 (Tue, 14 Sep 2004) | 1 line
Changed paths:
M /project1/trunk/Datei1
Added line to Datei1
------------------------------------------------------------------------
r2 | (no author) | 2004-09-14 12:22:30 +0200 (Tue, 14 Sep 2004) | 1 line
Changed paths:
A /project1/trunk/Datei1
New file Datei1
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log --stop-on-copy question
Posted by Greg Hudson <gh...@MIT.EDU>.
> if I run a
> svn log --stop-on-copy
> on a directory, it stops on the copy.
> If I run the same command on a file in that directory, it does not
> stop. (example below). Is that a bug or a feature? I'm running
> 1.1.0-rc3.
FSFS doesn't always follow copy history correctly when there are,
within a single revision, copy targets in multiple components of the
same path. As a result, it can wind up tracing history to the wrong
location and/or ignoring the --stop-on-copy flag. Thanks to CMike's
work on the reproduction recipe, I was able to fix this in relatively
short order (r10994 on the trunk).
The fix may not make it into 1.1.0 because it's not a critical bug and
we're in the final freeze period for that release. But it should make
it into 1.1.1 if not.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log --stop-on-copy question
Posted by Wolfgang Fritz <wo...@keymile.com>.
Ben Collins-Sussman wrote:
> Wolfgang Fritz wrote:
>
>> Hi,
>>
>> if I run a
>>
>> svn log --stop-on-copy
>>
>> on a directory, it stops on the copy.
>> If I run the same command on a file in that directory, it does not stop.
>> (example below). Is that a bug or a feature? I'm running 1.1.0-rc3.
>
> This is intentional, I think. The --stop-on-copy switch stops when the
> target is *explicitly* copied, rather than *implicitly* copied (because
> some parent was copied).
OK. I must say that I would like to have a consistent behaviour. If I do
svn log --stop-on-copy I want to know where an object has possibly been
copied from, no matter whether it was an implicit or an explicit copy.
But that's a matter of taste, I think.
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log --stop-on-copy question
Posted by "C. Michael Pilato" <cm...@collab.net>.
Wolfgang Fritz <wo...@keymile.com> writes:
> C. Michael Pilato wrote:
> I've not managed to reproduce the problem again. It's working as
> expected. I get only one "A" when I copy from trunk to a branch, and svn
> log --stop-on-copy stops at the same point for the directory and a file
> in the directory. So I must have done something wrong before. In future
> I will investigate more on my own before I post a problem.
If you still have the original repos, though, I'd still like to see a
dumpfile of it. It's seems clear to me that there was a real problem
at one point, reproducible or not. And I'd like to get to the bottom
of that problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log --stop-on-copy question
Posted by Wolfgang Fritz <wo...@keymile.com>.
C. Michael Pilato wrote:
> Wolfgang Fritz <wo...@keymile.com> writes:
>
>> > First, I'm not really sure that statement is true. Secondly, it's
>> > obvious from looking at Wolfgang's 'svn log' output that file in
>> > question *was* explicitly copied.
>> >
>>
>> I think Ben is right. I created the branch1 directory by a svn copy of
>> the source directory as a whole.
>
> The log shows that your file was copied explicitly by Subversion, even
> though you issue only one "svn copy" command. In other words, from
> the perspective of the repository code (and hench, the code that
> decides what to show for 'svn log'), you actually did four copies in
> the commit shown below:
>
>> > ------------------------------------------------------------------------
>> > r45 | (no author) | 2004-09-14 15:53:26 +0200 (Tue, 14 Sep 2004) | 1 line
>> > Changed paths:
>> > A /project1/branches/branch1 (from /project1/trunk:1)
>> > *** A /project1/branches/branch1/Datei1 (from /project1/trunk/Datei1:8)
>> > A /project1/branches/branch1/fdflush.c (from /project1/trunk/fdflush.c:5)
>> > A /project1/branches/branch1/modprobe.c (from /project1/trunk/modprobe.c:4)
>
> My guess is that you did a bunch of work without ever running 'svn
> update' on your tree, because when you copied trunk it was still at
> revision 1. In revision 1, trunk must not have had a child named
> Datei1, else that line in 'svn log' would have had an "R" action
> (replacement) instead of an "A" (addition).
>
Yes, that's probably true. I'm not quite sure when I have to submit a
svn update. I have to read more in "the book". So I could have done
something that produced the strange behaviour (see below)
>> This is a test repository for playing, so there would be no problem to
>> send you a dump. Unfortunately I've messed around with this repo too
>> much and the branch1 directory is in a different state now. I'll try to
>> set up a test case again.
>
I've not managed to reproduce the problem again. It's working as
expected. I get only one "A" when I copy from trunk to a branch, and svn
log --stop-on-copy stops at the same point for the directory and a file
in the directory. So I must have done something wrong before. In future
I will investigate more on my own before I post a problem.
BTW, I've tried to search the list before posting, but as I said in my
original message, the search function seems to be broken. I never see
newer messages as abt Oct 2003 in search results.
Sorry for all that noise,
Wolfgang
> That'd be great. Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log --stop-on-copy question
Posted by "C. Michael Pilato" <cm...@collab.net>.
Wolfgang Fritz <wo...@keymile.com> writes:
> > First, I'm not really sure that statement is true. Secondly, it's
> > obvious from looking at Wolfgang's 'svn log' output that file in
> > question *was* explicitly copied.
> >
>
> I think Ben is right. I created the branch1 directory by a svn copy of
> the source directory as a whole.
The log shows that your file was copied explicitly by Subversion, even
though you issue only one "svn copy" command. In other words, from
the perspective of the repository code (and hench, the code that
decides what to show for 'svn log'), you actually did four copies in
the commit shown below:
> > ------------------------------------------------------------------------
> > r45 | (no author) | 2004-09-14 15:53:26 +0200 (Tue, 14 Sep 2004) | 1 line
> > Changed paths:
> > A /project1/branches/branch1 (from /project1/trunk:1)
> > *** A /project1/branches/branch1/Datei1 (from /project1/trunk/Datei1:8)
> > A /project1/branches/branch1/fdflush.c (from /project1/trunk/fdflush.c:5)
> > A /project1/branches/branch1/modprobe.c (from /project1/trunk/modprobe.c:4)
My guess is that you did a bunch of work without ever running 'svn
update' on your tree, because when you copied trunk it was still at
revision 1. In revision 1, trunk must not have had a child named
Datei1, else that line in 'svn log' would have had an "R" action
(replacement) instead of an "A" (addition).
> This is a test repository for playing, so there would be no problem to
> send you a dump. Unfortunately I've messed around with this repo too
> much and the branch1 directory is in a different state now. I'll try to
> set up a test case again.
That'd be great. Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log --stop-on-copy question
Posted by Wolfgang Fritz <wo...@keymile.com>.
C. Michael Pilato wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
>> Wolfgang Fritz wrote:
>>
>> > Hi,
>> > if I run a
>> > svn log --stop-on-copy
>> > on a directory, it stops on the copy.
>> > If I run the same command on a file in that directory, it does not stop.
>> > (example below). Is that a bug or a feature? I'm running 1.1.0-rc3.
>>
>> This is intentional, I think. The --stop-on-copy switch stops when
>> the target is *explicitly* copied, rather than *implicitly* copied
>> (because some parent was copied).
>
> First, I'm not really sure that statement is true. Secondly, it's
> obvious from looking at Wolfgang's 'svn log' output that file in
> question *was* explicitly copied.
>
I think Ben is right. I created the branch1 directory by a svn copy of
the source directory as a whole.
> ------------------------------------------------------------------------
> r45 | (no author) | 2004-09-14 15:53:26 +0200 (Tue, 14 Sep 2004) | 1 line
> Changed paths:
> A /project1/branches/branch1 (from /project1/trunk:1)
> *** A /project1/branches/branch1/Datei1 (from /project1/trunk/Datei1:8)
> A /project1/branches/branch1/fdflush.c (from /project1/trunk/fdflush.c:5)
> A /project1/branches/branch1/modprobe.c (from /project1/trunk/modprobe.c:4)
>
> That said, I'm having trouble reproducing the problem for myself.
> Wolfgang, does the behavior change at all if you specify full URLs for
> your 'svn log' targets? And if the code isn't proprietary, could you
> post a compressed dumpfile of your repository somewhere so I could
> take a look-see? Thanks.
This is a test repository for playing, so there would be no problem to
send you a dump. Unfortunately I've messed around with this repo too
much and the branch1 directory is in a different state now. I'll try to
set up a test case again.
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log --stop-on-copy question
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> Wolfgang Fritz wrote:
>
> > Hi,
> > if I run a
> > svn log --stop-on-copy
> > on a directory, it stops on the copy.
> > If I run the same command on a file in that directory, it does not stop.
> > (example below). Is that a bug or a feature? I'm running 1.1.0-rc3.
>
> This is intentional, I think. The --stop-on-copy switch stops when
> the target is *explicitly* copied, rather than *implicitly* copied
> (because some parent was copied).
First, I'm not really sure that statement is true. Secondly, it's
obvious from looking at Wolfgang's 'svn log' output that file in
question *was* explicitly copied.
------------------------------------------------------------------------
r45 | (no author) | 2004-09-14 15:53:26 +0200 (Tue, 14 Sep 2004) | 1 line
Changed paths:
A /project1/branches/branch1 (from /project1/trunk:1)
*** A /project1/branches/branch1/Datei1 (from /project1/trunk/Datei1:8)
A /project1/branches/branch1/fdflush.c (from /project1/trunk/fdflush.c:5)
A /project1/branches/branch1/modprobe.c (from /project1/trunk/modprobe.c:4)
That said, I'm having trouble reproducing the problem for myself.
Wolfgang, does the behavior change at all if you specify full URLs for
your 'svn log' targets? And if the code isn't proprietary, could you
post a compressed dumpfile of your repository somewhere so I could
take a look-see? Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log --stop-on-copy question
Posted by Ben Collins-Sussman <su...@collab.net>.
Wolfgang Fritz wrote:
> Hi,
>
> if I run a
>
> svn log --stop-on-copy
>
> on a directory, it stops on the copy.
> If I run the same command on a file in that directory, it does not stop.
> (example below). Is that a bug or a feature? I'm running 1.1.0-rc3.
This is intentional, I think. The --stop-on-copy switch stops when the
target is *explicitly* copied, rather than *implicitly* copied (because
some parent was copied).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log --stop-on-copy question
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard <Ma...@softlanding.com> writes:
> I seem to recall ghudson fixing something related to how copies are
> handled internally in fsfs after RC1.
>
> Looking at the repository I think it might be r10480. You might take a
> look there first to see if it is related or perhaps even the fix?
>
> http://svn.collab.net/viewcvs/svn?rev=10480&view=rev
Nice, but I'm running newer code than that (r10988), and the original
bug report was against 1.1 rc2. This bug still exists.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log --stop-on-copy question
Posted by Mark Phippard <Ma...@softlanding.com>.
cmpilato@localhost.localdomain wrote on 09/16/2004 08:57:17 AM:
> Wolfgang Fritz <wo...@keymile.com> writes:
>
> > Hi,
> >
> > if I run a
> >
> > svn log --stop-on-copy
> >
> > on a directory, it stops on the copy.
> > If I run the same command on a file in that directory, it does not
stop.
> > (example below). Is that a bug or a feature? I'm running 1.1.0-rc3.
>
> Wolfgang, thanks for sending me your dumpfile. Congratulations, you
> found a real bug in the FSFS backend! I'm planning to hack on your
> dumpfile until the recipe is smaller, and core out your actual file
> data ('cause they don't matter none), and then file a public issue.
>
> See, persistance pays off. :-)
I seem to recall ghudson fixing something related to how copies are
handled internally in fsfs after RC1.
Looking at the repository I think it might be r10480. You might take a
look there first to see if it is related or perhaps even the fix?
http://svn.collab.net/viewcvs/svn?rev=10480&view=rev
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn log --stop-on-copy question
Posted by "C. Michael Pilato" <cm...@collab.net>.
Wolfgang Fritz <wo...@keymile.com> writes:
> Hi,
>
> if I run a
>
> svn log --stop-on-copy
>
> on a directory, it stops on the copy.
> If I run the same command on a file in that directory, it does not stop.
> (example below). Is that a bug or a feature? I'm running 1.1.0-rc3.
Wolfgang, thanks for sending me your dumpfile. Congratulations, you
found a real bug in the FSFS backend! I'm planning to hack on your
dumpfile until the recipe is smaller, and core out your actual file
data ('cause they don't matter none), and then file a public issue.
See, persistance pays off. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org