partial merging

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

partial merging

drkzs
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 ?

Thanx a lot,
and sorry for my english, i did my best ;)

drKzs

_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: partial merging

William Baum
drKzs,

Svnmerge, like any other subversion merge (and pretty much everything in subversion) is based on revisions, so its important to start thinking about these changes in terms of revisions rather than the specific changes to files and directories within those revisions.

so the unique solution to merge a part of the branch, is to use the -r option with revision number ?

Yes. If you are interested only in certain changes, you must determine and merge only the specific revisions you want.

After an svnmerge, i MUST commit all modifications of that merge, otherwise they won't be seen at the next svnmerge ?

Yes, but not just for that reason.  You'll generally want to make sure to commit all of the resulting changes from a merge (after resolving any conflicts), including all property changes. If you merge a revision without committing all of the changes, svnmerge (and subversion itself) will think changes have been merged that actually have not.  This will be extremely confusing to subversion, svnmerge, and any humans attempting to track the history of changes in the future.

Here are a few things I've found useful until you get the hang of it:

Do an 'svnmerge avail' and check the log of those revisions in the source branch to make sure things look correct.  This is also how you want to determine which revisions you do and don't want to merge.  The format of the svnmerge output is compatible with the merge -r parameter as well, so if you want to merge up to a given revision, say, you can cut and paste from the output of svnmerge avail.

If a merge goes bad, it's easily undone.  "svn revert . -R"  will roll back all of the changes except additions, which will be exposed with "svn st".  Simply delete the untracked files and directories and do an "svn up" and you should`be back where you were.

I wind up using "svn pl -v" a lot..

Hope this helps..

--Bill

On Mon, Jul 23, 2012 at 9:55 AM, drkmkzs <[hidden email]> 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 ?

Thanx a lot,
and sorry for my english, i did my best ;)

drKzs

_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge


_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: partial merging

Blair Zajac
In reply to this post by drkzs
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
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: partial merging

Jeppe_Oland
> 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 <[hidden email]>
Sent by: svnmerge-bounces+jeppe_oland=[hidden email]

07/23/2012 12:03 PM

To
drkmkzs <[hidden email]>,
cc
[hidden email]
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
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge


_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: partial merging

drkzs
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, [hidden email] <[hidden email]>:

>> 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 <[hidden email]>
> Sent by: svnmerge-bounces+jeppe_oland=[hidden email]
> 07/23/2012 12:03 PM
>
> To
> drkmkzs <[hidden email]>,
> cc
> [hidden email]
> 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
> [hidden email]
> http://www.orcaware.com/mailman/listinfo/svnmerge
>
>
_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge
Reply | Threaded
Open this post in threaded view
|

Re: partial merging

Blair Zajac
On 07/24/2012 01:49 AM, drkmkzs wrote:

> 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 ;)

Ideally each developer works on independent work and they all merge
their work back into trunk when it's ready.  Then you don't have cross
merges.

> 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 ?

Builtin svn merging allows for children to have different revisions
merged into it than parent directories.  But you're right, the simplest
form is for a single directory to have svn:mergeinfo on it.

Blair

_______________________________________________
Svnmerge mailing list
[hidden email]
http://www.orcaware.com/mailman/listinfo/svnmerge