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

Tobias Lang tlang303 at gmail.com
Thu Sep 6 12:33:40 PDT 2007


Thank you for your explanation Dale, but I am still not successful. The
smerge for 1.18.2 indeed worked well, but I don't get 1.18.3 working.
After trying I ended up with: *svk merge -ll -r 184:185
//mirror/secondlife/branches/Branch_1-18-3-Viewer //mirror/secondlifeAEL*
since the log command revealed that r184 is the first revision  of the
1-18-3 branch. It merges s.th. but I get compiler errors afterwards so s.th.
must be wrong.


On 9/6/07, Dale Glass <dale at daleglass.net> wrote:
>
> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070906/b4d64b6f/attachment.htm


More information about the SLDev mailing list