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