[sldev] Re: Problems merging new LL code with SVK source version control

[Dale Glass]

On Thursday 06 September 2007 17:44:10 Tobias Lang wrote:
> Hello,
>
> I make quite a lot of changes to the SL viewer and always struggle
> applying my changes to a new LL release. After following the
> instructions for the SVK version control
> http://wiki.secondlife.com/wiki/Source_version_control I can update to a
> new LL code very easliy, but only if I use the same branch, like 1.18.1.
> If LL releases a new viewer in another branch like 1.18.3 the "smerge"
> SVK command doesn't work anymore, telling me that no common merge base
> exists between the LL branch and my SVN repository.
>
> Is this a common problem or am I doing s.th. wrong? How to you guys
> usually update to a new version? Merging always manually?
>
> Thank you,
> Tobias

Ok, the trick is that SVK needs a continous history from where you started 
to where you are now to figure out what to merge, and LL sometimes screws 
it up. There seems to be some confusion regarding what LL works 
on, /release or /branch/Branch*, etc. Recently they first committed the 
1.18.2 changes into the 1.18.1 branch, THEN made 1.18.2 from that. So a 
smerge from 1.18.1 will work OK.

LL seems to branch inconsistently, sometimes they do it from /release, 
sometimes from /branches/Branch*. So long the branch is from the previous 
one smerge should work.

For SL it's pretty easy anyway: You need to find the first revision after 
you merged and merge from there with 'svk merge' instead of 'svk smerge'. 
Doing that will create a merge point, and after that you can use smerge 
again.

The -C argument will test a merge without actually doing it, you can use 
that to safely play with the revision arguments until you get it right.

You can find the revision by using svk log.

Some hints: 

Use the -I (uppercase I as in the first character of "information" for 
those with evil fonts) argument to smerge. That results in a merge being 
done revision by revision instead of as one big chunk. If you're 5 
revisions behind, without -I you're merging all 5 as one into the 
destination, while with -I you'll commit 5. That makes things a lot 
friendlier for external SVN users, and makes things much nicer for you if 
you need to merge the results of the merge somewhere else.

The -l (lowercase L as in "land") argument will copy log entries. -Il will 
merge revision by revision, copying the original log entries so that you 
don't have to enter your own.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070906/cc6693da/attachment.pgp