On 1/31/07, Rob Hubbard <Rob.Hubbard@celoxica.com> wrote:
>
> Johan,
>
> When you use "cvs" below, I presume you mean "svn" (perhaps you've aliased
> the command).
Yes of course, it sould be "svn" (I'm using both, so sometimes I mix them
up).
The "svn mv" commands are significant. It may be that "trunk/subdir" existed
> back to revision 1 (even if it has been moved), but that the trunk into
> which it has been moved does not. Was the "trunk" directory *created*
> (without being moved or copied from something else) at around revision 900?
Yes I think you are right. I guess the the significant revisions are those
given below (note that the actual subdir name is "tcs" and not "subdir" as
in my previous example).
======================
r903 | holmberg | 2006-10-11 09:36:17 +0200 (on, 11 okt 2006) | 2 lines
Changed paths:
A /base/trunk/tcs (from /base/trunk/trunk:902)
D /base/trunk/trunk
-----------------------------------
r902 | holmberg | 2006-10-11 09:35:54 +0200 (on, 11 okt 2006) | 2 lines
Changed paths:
D /base/tcs/trunk
A /base/trunk/trunk (from /base/tcs/trunk:901)
-----------------------------------
r901 | holmberg | 2006-10-11 09:34:38 +0200 (on, 11 okt 2006) | 2 lines
Changed paths:
A /base/trunk
======================
I made those changes rather "naively" in the repository browser of
TortoiseSVN. I had no idea that it should have such consequences.
Until my current "incident" I have imagined that a "svn log" command would
operate by returning *all* revisions after *filtering* to only show those
revisions that affects files *currently* under a given path (even if they
were somewhere else before).
Note that "http://svn.server/my/proj/trunk" may not be the same object in
> different revisions. Have a read of the SVN book about peg revisions.
Thanks for the tip. I'll have to read it carefully later to understand if it
applies to my current situation.
/Johan Holmberg
What range of revisions do you get with
> svn log -q --stop-on-copy http://svn.server/my/proj/trunk/subdir
> ?
>
> What do you get with, say,
> svn log -q http://svn.server/my/proj/trunk@450
> ?
>
> Rob.
>
> > -----Original Message-----
> > From: johan556@gmail.com [mailto:johan556@gmail.com]
> > Sent: 31 January 2007 10:55
> > To: users@subversion.tigris.org
> > Subject: "svn log" not reaching revision 1
> >
> >
> > Hi!
> >
> > I tried to run "svn log -v" on the top of one of my projects, and was
> > surprised that the revisions returned "stopped" at a certain number
> > (e.g. 901). The revisions shown were then 1209-901, and revision 900-1
> > seemed to have disappeared. But when I ran "svn log -v" on a
> > subdirectory of the project I got all revisions 1209-1.
> >
> > The commands I used were:
> >
> > $ cvs log -v http://svn.server/my/proj/trunk
> > # gives 1209-901
> > $ cvs log -v http://svn.server/my/proj/trunk/subdir #
> > gives 1200-1
> >
> > I also tried to give an explicit "-r1209:1" option, but that didn't
> > change anything.
> >
> > I have looked at the revisions around 901, suspecting that I might
> > have done something that Subversion "didn't like". Some of the commits
> > were reorganizations (e.g. svn mv) of the top directories of the
> > project. But should such operations really be that harmful?
> >
> > Other than these observations I have no clue as to what is wrong. Can
> > anybody help me explain what is going on?
> >
> > /Johan Holmberg
>
> _____________________________________________________________________
> This message has been checked for all known viruses by the MessageLabs
> Virus Scanning Service, on behalf of Celoxica Ltd.
>
> This email and any files transmitted with it are confidential and
> may be legally privileged. It is intended solely for the use of the
> individual or entity to whom it is addressed. If you have received
> this in error, please contact the sender and delete the material
> immediately. Whilst this email has been swept for viruses, you
> should carry out your own virus check before opening any
> attachment. Celoxica Ltd accepts no liability for any loss or
> damage which may be caused by software viruses or interception
> or interruption of this email.
>
Received on Wed Jan 31 14:24:40 2007