[Svnmerge] partial merging

drkmkzs drkmkzs at gmail.com
Tue Jul 24 01:49:57 PDT 2012


Thanks Bill and Blair for these answers,

I begin to understand now how does svnmerge work.

The difficulty seems to be determining which revision we want to
commit, because several people work on the devel branches, and
sometimes you want just to merge some modifications, and not other
functionalities still under development... So I guess we have to be
very carefull when choosing the revisions, it was more simple to
choose the files or folders.

But I do understand why it has to work like this.

Maybe our problem is that we should all have our own devel branch...
but it would raise another problem, merging in each devel branch the
modifications done by other developpers in their own branches... arg,
I have an headache ;)

Blair, you said
>> If you want per-file merging, then switch to svn's builtin merge-tracking

I thought the svn's builtin mechanism would be the same, setting
properties on the top level directory of the branch, so the problem is
still the same ?

thanks,
and thanks for my english ;)



2012/7/23, Jeppe_Oland at playstation.sony.com <Jeppe_Oland at playstation.sony.com>:
>> If you are on svn 1.6 or 1.7, I would definitely recommend switching to
>> svn's builtin merge-tracking.  The only feature that svnmerge.py
>> provides is blocking of revisions, but this can be faked with svn using
>> merge's --record-only command line option.
>
> I was under the impression that SVN still doesn't support cross-repo merge
> tracking...
>
> Regards,
> -Jeppe
>
>
>
>
> Blair Zajac <blair at orcaware.com>
> Sent by: svnmerge-bounces+jeppe_oland=playstation.sony.com at orcaware.com
> 07/23/2012 12:03 PM
>
> To
> drkmkzs <drkmkzs at gmail.com>,
> cc
> svnmerge at orcaware.com
> Subject
> Re: [Svnmerge] partial merging
>
>
>
>
>
>
> On 07/23/2012 07:55 AM, drkmkzs wrote:
>> Hello,
>>
>> I've just begun to use svnmerge, and I had some little problems,
>> surely due to my misusing, or my misunderstanding :)
>>
>> We have a trunk branch, and we branched a devel branch from it.
>> We work on the devel branch, commit, etc etc... Then when want to merge.
>>
>> We went the trunk local repository, ensured it's up-to-date, and did
> svnmerge.
>> All was fine, we could see all modifications on the local repository.
>>
>> The problem was at the next step :
>>> we believed we could commit just the modifications on some files we
> want, so we just committed some files. For the rest of the files - that
> were merged but we didn't want to commit - we just replaced them with the
> head version (i think the bad usage is here)
>>
>> Then we continue to work on the devel.
>>
>> Then we wanted to process a second merge. But after the svnmerge, all
>> modifications that had not been committed at the first merge were not
>> merged. It was like svnmerge had skipped them...
>> To get them back, i had to uninit the trunk branch, and do the process
> again.
>>
>> Is my understanding correct ? After an svnmerge, i MUST commit all
>> modifications of that merge, otherwise they won't be seen at the next
>> svnmerge ?
>> => so the unique solution to merge a part of the branch, is to use the
>> -r option with revision number ?
>
> Right.  With svnmerge.py, one needs to commit all files from the merged
> revision(s), it's all or nothing.  If you want per-file merging, then
> switch to svn's builtin merge-tracking.
>
> If you are on svn 1.6 or 1.7, I would definitely recommend switching to
> svn's builtin merge-tracking.  The only feature that svnmerge.py
> provides is blocking of revisions, but this can be faked with svn using
> merge's --record-only command line option.
>
>> Thanx a lot,
>> and sorry for my english, i did my best ;)
>
> Pretty good English ;)
>
> Regards,
> Blair
> _______________________________________________
> Svnmerge mailing list
> Svnmerge at orcaware.com
> http://www.orcaware.com/mailman/listinfo/svnmerge
>
>


More information about the Svnmerge mailing list