Guille -bisho- wrote:
> Our situation is the following: We have several environments,
> development, testing and release and we want to commit from time to time
> to testing several changes from development to testing when some
> changesets correct a bug or implement a feature. After testing they are
> eventually moved to release, but the order or the additions to the
> development environment is not the same order of deploying on
> testing/release, so we have to play a lot with merges, and we don't
> wan't to copy the last version of files from devel in the case of a
> move, just execute that "move" on testing/release.
>
> Is a very different and strange use-case compared to the normal way of
> development in Open Source products. :(
>
> Anyway, we will see how we could overcome our problem treating moves by
> hand.
The best pratical advice I've come up with for keeping commits
"merge flexibile" is to try to make each commit do one simple thing,
ideally only touching a few files. This may mean checking your
outstanding changes in as multiple independent commits (this is a
good idea for other reasons too).
E.g., if you have a commit that touches a lot of files, then the
chances increase that this commit cannot be merged into another
tree due to one of those files having been added in a previous,
not-yet-merged revision.
Also, svnmerge may help... http://www.dellroad.org/svnmerge/index
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 18 16:30:49 2004