[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Merging Practices

From: Sean Laurent <sean_at_neuronfarm.com>
Date: 2005-01-31 17:52:34 CET

I have been doing a lot of merging recently and I occasionally get results
that aren't what I expect. They actually make sense when I think them
through, but they're not what I want. *grin*

Our repository is setup in the following manner:

main/
branches/
tags/

I needed to do some work that I expected would take me 1-2 weeks and might
break the build. So, I created a task branch for myself:

$ svn up main
At revision 805

$ svn copy -r 805 http://server/svn/apps/main
http://server/svn/apps/branches/mytask -m "My task from r805."
...
Committed revision 806.

I work on 'mytask' for a couple of days. In the meanwhile, I have to fix a
bug in the main dev-line that also needs to get fixed in mytask. After
committing that change in r810, I merge the changes from main into mytask:

$ svn merge -r 807:810 http://server/svn/apps/main mytask

This works without a flaw, so I commit it. A few days pass and development on
the main branch has been going gangbusters and I'm just about ready to merge
my branch changes back into main. To prepare, I merge main into mytask one
more time.

$ svn up main
At revision 833.

$ svn merge -r 811:833 http://server/svn/apps/main mytask

This time, things don't go as smoothly. We have several developers working in
Flash MX and they regularly commit binary FLA files. Even though I
personally haven't touched a single FLA file in any branch, I get a bunch of
conflicts on FLA files:

$ ls mytask/flashsrc/fla/global/core/Template.fla*
mytask/flashsrc/fla/global/core/Template.fla
mytask/flashsrc/fla/global/core/Template.fla.merge-left.r811
mytask/flashsrc/fla/global/core/Template.fla.merge-left.r833
mytask/flashsrc/fla/global/core/Template.fla.working

I double check the mime-type:

$ svn pg svn:mime-type mytask/flashsrc/fla/global/core/Template.fla
application/octet-stream

On one level, this makes sense. I asked Subversion to find the changes on
main between r811 and r833 and apply those changes to my working copy. Since
the FLA files are binary, Subversion can't merge them. So, I guess that
makes sense. However, I still don't understand why I get a .working copy if
I didn't modify the the file in my WC.

Unfortunately, in every case of a conflict for binary files, I simply want to
replace the version in my WC (for this branch) with the latest revision from
main. I could (and did) write a little shell script to find all conflicted
fla files, delete the .fla, delete the .fla.merge-left.r811, delete
the .fla.working and rename the .fla.merge-right.r833 to .fla. However, it
seems like there might be a better way to do this. Especially since I really
don't want to even bother to try merging the FLA files ...

Any suggestions on how to improve my merge practices?

-Sean
------------------------------
The one good thing about repeating your mistakes is that you know when to
cringe.
------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jan 31 17:54:48 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.