[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Dan Stromberg <dstromberglists_at_gmail.com>
Date: Thu, 03 Apr 2008 18:34:59 -0700

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_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-04 07:56:34 CEST

This is an archived mail posted to the Subversion Users mailing list.