You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Dan Stromberg <ds...@gmail.com> on 2008/04/03 21:02:44 UTC

What I really want is to be able to "svn log" back to the beginning of repo time

If I run a basic "svn log" command like:

    $ svn log http://eng2/svn/Datallegro/branches/v3.1.4-dev | wc -l
    128

...as you can see, I get a tiny number of lines - but there should be 
thousands if svn is going back to the beginning of repository history as 
I keep hearing it's supposed to.  And we could really use complete history.

I get that same short result whether using an svn 1.1.4 client on CentOS 
4.6, or an svn 1.4.4 client on openSUSE 10.3.  In both cases, the 
clients are talking to an svn 1.1.4 server via WebDAV with FSFS backends 
on CentOS 4.6.

I know, 1.1.4 is really old.  I doubt my management is going to go for 
an upgrade without a really good reason though.  Is there much chance 
that upgrading the subversion (and 3 repositories) on our server to 
1.4.6 would help "svn log" go back to the beginning of time like it 
should?  Or would it at least fix new commits?

Thanks!




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: What I really want is to be able to "svn log" back to the beginning of repo time

Posted by Lorenz <lo...@yahoo.com>.
Ryan Schmidt wrote:
>[...]
>What? No... "svn switch" does nothing to your repository. It just  
>changes your working copy so that it's attached to a different part  
>of the repository. It doesn't remove anything from the repository, or  
>change the repository in any way.

and svn switch needs an existing target to switch to, that is the new
branch needs to be created in the repositiory first. And if you create
an empty folder (not as a copy of something else that is), svn switch
will clear out your wc.
-- 

Lorenz


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: What I really want is to be able to "svn log" back to the beginning of repo time

Posted by Hari Kodungallur <hk...@gmail.com>.
On Thu, Apr 3, 2008 at 5:13 PM, Ryan Schmidt <
subversion-2008a@ryandesign.com> wrote:

>
>  I am afraid this is not the best way to create the branches. 'svn switch'
> > will completely switch (move) your branch to a new location in the
> > repository. And when you do this (a) it will remove your old branch and (b)
> > it will leave no trace of history for the new branch.
> >
>
> What? No... "svn switch" does nothing to your repository. It just changes
> your working copy so that it's attached to a different part of the
> repository. It doesn't remove anything from the repository, or change the
> repository in any way.



Oops.. my bad. Please disregard this portion of what I said. I am not even
sure what I was thinking. It is not like this something I did not know..
Weird.

Thanks,
-Hari

Re: What I really want is to be able to "svn log" back to the beginning of repo time

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Apr 3, 2008, at 20:34, Dan Stromberg wrote:

> Ryan Schmidt wrote:
>> On Apr 3, 2008, at 17:21, Hari Kodungallur wrote:
>>
>>> On Thu, Apr 3, 2008 at 2:40 PM, Dan Stromberg wrote:
>>>
>>>> This is kind of interesting:
>>>>
>>>>   $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev
>>>>   --stop-on-copy | wc -l
>>>>   199
>>>>   eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above  
>>>> cmd
>>>>   done 2008 Thu Apr 03 02:24 PM
>>>>
>>>>   $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev |  
>>>> wc -l
>>>>   199
>>>>   eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above  
>>>> cmd
>>>>   done 2008 Thu Apr 03 02:24 PM
>>>>
>>>> It seems to stop at the same place --stop-on-copy does.
>>
>> This means that the branch was not created by copying something  
>> else, but by creating it from scratch.
> No wonder then.
>
>>>> The way we create new branches is to:
>>>> 1) "svn checkout" the source branch nonrecursively - this  
>>>> doesn't really check out much
>>>> 2) modify the external references at the top level
>>>> 3) do an "svn update" to get the rest of the code - this checks  
>>>> out a lot
>>>> 4) modify a few remaining externals
>>>> 5) "svn update" again
>>>> 6) "svn switch" to name the checked out code to something new
>>>> 7) "svn commit"
>>>>
>>>> Is that appropriate?  I don't have a huge amount of SCM  
>>>> experience, and inherited most of this process.
>>
>> Sounds very weird. Normally to create branch you should:
>>
>> svn copy -r 123 $REPO/trunk $REPO/branches/my_new_branch \
>> -m "making my_new_branch from revision 123 of trunk"
> I'd be overjoyed to do it this way, but instead of having a simple  
> $REPO/trunk and $REPO/branches and $REPO/tags, we have...  Normal  
> $REPO/branches, Normal $REPO/tags, and trunk is made up of $REPO/ 
> part1, $REPO/part2 ... $REPO/partn (not really numbered, but you  
> probably get the idea).  Then we have $REPO/FullDist which has  
> externals for parts 1..n to, at least in a limited sense, relate  
> them to each other.
>>> My suggestion will be to do the following (if you can make it a  
>>> script, it will be better).
>>> - 'svn copy' your tree to a branch directory
>>> - separately checkout -N (non-recursive) each directory within  
>>> the new branch where the externals have to be set.
>>> - update the externals for each of these directories and check-in  
>>> each directory
> So would it look like:
>
> svn copy $REPO/FullDist $REPO/branches/v5.6.7
> svn checkout $REPO/branches/v5.6.7
> cd v5.6.7
> svn checkout -N $REPO/part1 # might do these parts by sed'ing the  
> top-level externals - they aren't really numbered
> svn checkout -N $REPO/part2
> ...
> svn checkout -N $REPO/partn

These part1 thru partn checkouts will be entirely separate working  
copies. The main v5.6.7 working copy will not know anything about them.

> unified-external-updater . # something I wrote to sed our  
> externals, recursively
> svn commit

The only thing that would be committed here is the changes your  
script makes to the externals.

> ?
>
> Or would this work:
>
> svn copy $REPO/FullDist $REPO/branches/v5.6.7
> svn copy $REPO/part1 $REPO/branches/v5.6.7/part1
> svn copy $REPO/part1 $REPO/branches/v5.6.7/part2
> ...
> svn copy $REPO/part1 $REPO/branches/v5.6.7/partn

You could do that. Make sure to specify an explicit revision (-r  
123), and that it's the same version for all the copy commands. That  
way you get a consistent branch based on a single revision of your  
project.


> svn checkout $REPO/branches/v5.6.7
> cd v5.6.7
> unified-external-updater . # attempt to do all the externals at once
> # do we need an "svn update" here?

It would check out working copies for each of your externals  
definitions. If you want for that to happen, you should update.


> svn commit
>
> ?
>
> BTW, is it important to use this sort of procedure for every  
> external individually?  We have a handful of them down deeper in  
> the tree too.

I've really lost track of the scenario by now so I don't know.

It would make more sense if you would have your entire project under  
a single directory "trunk" so that you could make branches in a sane  
way. You could then use the "svncopy.pl" script to automatically fix  
externals definitions to include a revision argument, for example.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: What I really want is to be able to "svn log" back to the beginning of repo time

Posted by Dan Stromberg <ds...@gmail.com>.
Ryan Schmidt wrote:
> On Apr 3, 2008, at 17:21, Hari Kodungallur wrote:
>
>> On Thu, Apr 3, 2008 at 2:40 PM, Dan Stromberg wrote:
>>
>>> This is kind of interesting:
>>>
>>>   $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev
>>>   --stop-on-copy | wc -l
>>>   199
>>>   eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above cmd
>>>   done 2008 Thu Apr 03 02:24 PM
>>>
>>>   $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev | wc -l
>>>   199
>>>   eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above cmd
>>>   done 2008 Thu Apr 03 02:24 PM
>>>
>>> It seems to stop at the same place --stop-on-copy does.
>
> This means that the branch was not created by copying something else, 
> but by creating it from scratch.
No wonder then.

>>> The way we create new branches is to:
>>> 1) "svn checkout" the source branch nonrecursively - this doesn't 
>>> really check out much
>>> 2) modify the external references at the top level
>>> 3) do an "svn update" to get the rest of the code - this checks out 
>>> a lot
>>> 4) modify a few remaining externals
>>> 5) "svn update" again
>>> 6) "svn switch" to name the checked out code to something new
>>> 7) "svn commit"
>>>
>>> Is that appropriate?  I don't have a huge amount of SCM experience, 
>>> and inherited most of this process.
>
> Sounds very weird. Normally to create branch you should:
>
> svn copy -r 123 $REPO/trunk $REPO/branches/my_new_branch \
> -m "making my_new_branch from revision 123 of trunk"
I'd be overjoyed to do it this way, but instead of having a simple 
$REPO/trunk and $REPO/branches and $REPO/tags, we have...  Normal 
$REPO/branches, Normal $REPO/tags, and trunk is made up of $REPO/part1, 
$REPO/part2 ... $REPO/partn (not really numbered, but you probably get 
the idea).  Then we have $REPO/FullDist which has externals for parts 
1..n to, at least in a limited sense, relate them to each other.
>> My suggestion will be to do the following (if you can make it a 
>> script, it will be better).
>> - 'svn copy' your tree to a branch directory
>> - separately checkout -N (non-recursive) each directory within the 
>> new branch where the externals have to be set.
>> - update the externals for each of these directories and check-in 
>> each directory
So would it look like:

svn copy $REPO/FullDist $REPO/branches/v5.6.7
svn checkout $REPO/branches/v5.6.7
cd v5.6.7
svn checkout -N $REPO/part1 # might do these parts by sed'ing the 
top-level externals - they aren't really numbered
svn checkout -N $REPO/part2
...
svn checkout -N $REPO/partn
unified-external-updater . # something I wrote to sed our externals, 
recursively
svn commit

?

Or would this work:

svn copy $REPO/FullDist $REPO/branches/v5.6.7
svn copy $REPO/part1 $REPO/branches/v5.6.7/part1
svn copy $REPO/part1 $REPO/branches/v5.6.7/part2
...
svn copy $REPO/part1 $REPO/branches/v5.6.7/partn
svn checkout $REPO/branches/v5.6.7
cd v5.6.7
unified-external-updater . # attempt to do all the externals at once
# do we need an "svn update" here?
svn commit

?

BTW, is it important to use this sort of procedure for every external 
individually?  We have a handful of them down deeper in the tree too.

Thanks much folks.






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: What I really want is to be able to "svn log" back to the beginning of repo time

Posted by Ryan Schmidt <su...@ryandesign.com>.
On Apr 3, 2008, at 17:21, Hari Kodungallur wrote:

> On Thu, Apr 3, 2008 at 2:40 PM, Dan Stromberg wrote:
>
>> This is kind of interesting:
>>
>>   $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev
>>   --stop-on-copy | wc -l
>>   199
>>   eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above cmd
>>   done 2008 Thu Apr 03 02:24 PM
>>
>>   $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev | wc -l
>>   199
>>   eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above cmd
>>   done 2008 Thu Apr 03 02:24 PM
>>
>> It seems to stop at the same place --stop-on-copy does.

This means that the branch was not created by copying something else,  
but by creating it from scratch.


>> The way we create new branches is to:
>> 1) "svn checkout" the source branch nonrecursively - this doesn't  
>> really check out much
>> 2) modify the external references at the top level
>> 3) do an "svn update" to get the rest of the code - this checks  
>> out a lot
>> 4) modify a few remaining externals
>> 5) "svn update" again
>> 6) "svn switch" to name the checked out code to something new
>> 7) "svn commit"
>>
>> Is that appropriate?  I don't have a huge amount of SCM  
>> experience, and inherited most of this process.

Sounds very weird. Normally to create branch you should:

svn copy -r 123 $REPO/trunk $REPO/branches/my_new_branch \
-m "making my_new_branch from revision 123 of trunk"


>> I suspect we may be doing it this way because our trunk is  
>> scattered all over, but we have a single subversion directory with  
>> external references that unifies the pieces.
>>
>> Is the alternative to do one "svn copy" for every external reference?

Don't understand how your trunk "is scattered all over"...


> I am afraid this is not the best way to create the branches. 'svn  
> switch' will completely switch (move) your branch to a new location  
> in the repository. And when you do this (a) it will remove your old  
> branch and (b) it will leave no trace of history for the new branch.

What? No... "svn switch" does nothing to your repository. It just  
changes your working copy so that it's attached to a different part  
of the repository. It doesn't remove anything from the repository, or  
change the repository in any way.


> My suggestion will be to do the following (if you can make it a  
> script, it will be better).
> - 'svn copy' your tree to a branch directory
> - separately checkout -N (non-recursive) each directory within the  
> new branch where the externals have to be set.
> - update the externals for each of these directories and check-in  
> each directory



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: What I really want is to be able to "svn log" back to the beginning of repo time

Posted by Hari Kodungallur <hk...@gmail.com>.
On Thu, Apr 3, 2008 at 2:40 PM, Dan Stromberg <ds...@gmail.com>
wrote:

> Hari Kodungallur wrote:
>
>
> > On Thu, Apr 3, 2008 at 2:02 PM, Dan Stromberg <dstromberglists@gmail.com<mailto:
> > dstromberglists@gmail.com>> wrote:
> >
> >
> >    If I run a basic "svn log" command like:
> >
> >      $ svn log http://eng2/svn/Datallegro/branches/v3.1.4-dev | wc -l
> >      128
> >
> >    ...as you can see, I get a tiny number of lines - but there should
> >    be thousands if svn is going back to the beginning of repository
> >    history as I keep hearing it's supposed to.  And we could really
> >    use complete history.
> >
> >    I get that same short result whether using an svn 1.1.4 client on
> >    CentOS 4.6, or an svn 1.4.4 client on openSUSE 10.3.  In both
> >    cases, the clients are talking to an svn 1.1.4 server via WebDAV
> >    with FSFS backends on CentOS 4.6.
> >
> >    I know, 1.1.4 is really old.  I doubt my management is going to go
> >    for an upgrade without a really good reason though.  Is there much
> >    chance that upgrading the subversion (and 3 repositories) on our
> >    server to 1.4.6 would help "svn log" go back to the beginning of
> >    time like it should?  Or would it at least fix new commits?
> >
> >    Thanks!
> >
> >
> >
> > The default behaviour of svn is traverse the history of the branch when
> > doing svn log. So you should have got all the history until the beginning of
> > time. Please look at the entire content of the 'svn log' and see where it
> > stops.
> >
> > Did you create the branch using the 'svn copy' command? Or was it
> > populated from a local copy of source code or something like that? I know
> > that sounds like something no one would do; but I can not imagine a scenario
> > where svn will not print the whole history of a branch. Basically if you do
> > "svn log -v URL --stop-on-copy" and then look at the very last printed
> > revision, you will be able to tell how the branch was created?
> >
> >
> > Regards,
> > -Hari
> >
> I'm afraid we are probably checking out, changing and checking in, like
> you said no one would do :)
>
> This is kind of interesting:
>
>   $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev
>   --stop-on-copy | wc -l
>   199
>   eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above cmd
>   done 2008 Thu Apr 03 02:24 PM
>
>   $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev | wc -l
>   199
>   eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above cmd
>   done 2008 Thu Apr 03 02:24 PM
>
> It seems to stop at the same place --stop-on-copy does.
>
> The way we create new branches is to:
> 1) "svn checkout" the source branch nonrecursively - this doesn't really
> check out much
> 2) modify the external references at the top level
> 3) do an "svn update" to get the rest of the code - this checks out a lot
> 4) modify a few remaining externals
> 5) "svn update" again
> 6) "svn switch" to name the checked out code to something new
> 7) "svn commit"
>
> Is that appropriate?  I don't have a huge amount of SCM experience, and
> inherited most of this process.
>
> I suspect we may be doing it this way because our trunk is scattered all
> over, but we have a single subversion directory with external references
> that unifies the pieces.
>
> Is the alternative to do one "svn copy" for every external reference?
>
>

I am afraid this is not the best way to create the branches. 'svn switch'
will completely switch (move) your branch to a new location in the
repository. And when you do this (a) it will remove your old branch and (b)
it will leave no trace of history for the new branch.

My suggestion will be to do the following (if you can make it a script, it
will be better).
- 'svn copy' your tree to a branch directory
- separately checkout -N (non-recursive) each directory within the new
branch where the externals have to be set.
- update the externals for each of these directories and check-in each
directory

Hope this helps,
rgds,
-Hari

Re: What I really want is to be able to "svn log" back to the beginning of repo time

Posted by Dan Stromberg <ds...@gmail.com>.
Hari Kodungallur wrote:
>
> On Thu, Apr 3, 2008 at 2:02 PM, Dan Stromberg 
> <dstromberglists@gmail.com <ma...@gmail.com>> wrote:
>
>
>     If I run a basic "svn log" command like:
>
>       $ svn log http://eng2/svn/Datallegro/branches/v3.1.4-dev | wc -l
>       128
>
>     ...as you can see, I get a tiny number of lines - but there should
>     be thousands if svn is going back to the beginning of repository
>     history as I keep hearing it's supposed to.  And we could really
>     use complete history.
>
>     I get that same short result whether using an svn 1.1.4 client on
>     CentOS 4.6, or an svn 1.4.4 client on openSUSE 10.3.  In both
>     cases, the clients are talking to an svn 1.1.4 server via WebDAV
>     with FSFS backends on CentOS 4.6.
>
>     I know, 1.1.4 is really old.  I doubt my management is going to go
>     for an upgrade without a really good reason though.  Is there much
>     chance that upgrading the subversion (and 3 repositories) on our
>     server to 1.4.6 would help "svn log" go back to the beginning of
>     time like it should?  Or would it at least fix new commits?
>
>     Thanks!
>
>
>
> The default behaviour of svn is traverse the history of the branch 
> when doing svn log. So you should have got all the history until the 
> beginning of time. Please look at the entire content of the 'svn log' 
> and see where it stops.
>
> Did you create the branch using the 'svn copy' command? Or was it 
> populated from a local copy of source code or something like that? I 
> know that sounds like something no one would do; but I can not imagine 
> a scenario where svn will not print the whole history of a branch. 
> Basically if you do "svn log -v URL --stop-on-copy" and then look at 
> the very last printed revision, you will be able to tell how the 
> branch was created?
>
>
> Regards,
> -Hari
I'm afraid we are probably checking out, changing and checking in, like 
you said no one would do :)

This is kind of interesting:

    $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev
    --stop-on-copy | wc -l
    199
    eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above cmd
    done 2008 Thu Apr 03 02:24 PM

    $ svn log -v http://eng2/svn/Datallegro/branches/v3.1.4-dev | wc -l
    199
    eng2-da_build:~/.subversion i686-redhat-linux-gnu 8879 - above cmd
    done 2008 Thu Apr 03 02:24 PM

It seems to stop at the same place --stop-on-copy does.

The way we create new branches is to:
1) "svn checkout" the source branch nonrecursively - this doesn't really 
check out much
2) modify the external references at the top level
3) do an "svn update" to get the rest of the code - this checks out a lot
4) modify a few remaining externals
5) "svn update" again
6) "svn switch" to name the checked out code to something new
7) "svn commit"

Is that appropriate?  I don't have a huge amount of SCM experience, and 
inherited most of this process.

I suspect we may be doing it this way because our trunk is scattered all 
over, but we have a single subversion directory with external references 
that unifies the pieces.

Is the alternative to do one "svn copy" for every external reference?

Thanks!



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: What I really want is to be able to "svn log" back to the beginning of repo time

Posted by Hari Kodungallur <hk...@gmail.com>.
On Thu, Apr 3, 2008 at 2:02 PM, Dan Stromberg <ds...@gmail.com>
wrote:

>
> If I run a basic "svn log" command like:
>
>   $ svn log http://eng2/svn/Datallegro/branches/v3.1.4-dev | wc -l
>   128
>
> ...as you can see, I get a tiny number of lines - but there should be
> thousands if svn is going back to the beginning of repository history as I
> keep hearing it's supposed to.  And we could really use complete history.
>
> I get that same short result whether using an svn 1.1.4 client on CentOS
> 4.6, or an svn 1.4.4 client on openSUSE 10.3.  In both cases, the clients
> are talking to an svn 1.1.4 server via WebDAV with FSFS backends on CentOS
> 4.6.
>
> I know, 1.1.4 is really old.  I doubt my management is going to go for an
> upgrade without a really good reason though.  Is there much chance that
> upgrading the subversion (and 3 repositories) on our server to 1.4.6 would
> help "svn log" go back to the beginning of time like it should?  Or would it
> at least fix new commits?
>
> Thanks!



The default behaviour of svn is traverse the history of the branch when
doing svn log. So you should have got all the history until the beginning of
time. Please look at the entire content of the 'svn log' and see where it
stops.

Did you create the branch using the 'svn copy' command? Or was it populated
from a local copy of source code or something like that? I know that sounds
like something no one would do; but I can not imagine a scenario where svn
will not print the whole history of a branch. Basically if you do "svn log
-v URL --stop-on-copy" and then look at the very last printed revision, you
will be able to tell how the branch was created?


Regards,
-Hari