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
[email protected]
http://www.orcaware.com/mailman/listinfo/svnmerge
