On 11.09.2009 17:33, Kristoffer Lundén wrote:
> Hello,
>
> I was wondering if you could help me with a use case I have.
>
> We develop in several repositories that have interdependencies and also
> using multiple branches. Even so, the repositories are huge and merges
> take a long time and can be a bit on the complex side.
>
> For these and other reasons, the repositories are kept under a certain
> amount of control, and when it is time to reintegrate changes, or to
> spread the same changes to other branches, we have one central
> “authority” (could be me) that makes all the merges across the board,
> and then distributes the not easily solved conflicts to the different
> people that should take care of them.
>
> The way this is done currently is to do the merge, choose “resolve all
> later” when any conflict dialog appears and for all conflicts that are
> not obvious and easy we copy all the paths to send out to the experts on
> the respective areas.
>
> We also commit everything that has already been properly merged, and
> then we turn over the list of conflicts to the experts.
>
> And here is the problem – we haven’t found a good way for them to repeat
> the same merge, only getting these changes, so that they can easily fix
> it up using tortoise or other similar tool:
>
> If we choose to resolve all conflicts so that we can commit them, then
> the changes are naturally marked as merged and fixed – not what we want.
>
> But if we revert the conflicted files and commit all the rest, we also
> can not repeat the previous merge. I **think** that this is because
> svn:mergeinfo properties are inherited from parent paths, but I am not
> entirely sure.
>
> The result is that the poor developers need to manually open both paths
> for each file in a merge tool, which is really really really tedious to
> do when you have 10, 20 or 50 files to have a look at… J
>
> So, the question is if anybody has any good ideas on how we could solve
> this little workflow problem? We are happy enough with the process
> (although **ideas** are always welcome) as it fits our scenarios, but it
> would be extremely helpful if we could:
>
> 1. Do a complete merge
> 2. Ignore any harder conflict, making a note of the files to check
> that all are fixed later
> 3. Commit all that went well in the merge
> 4. Hand over a list of revisions merged and what branches + the above
> list to developers
> 5. The developers repeat the exact same merge interval and get the
> same remaining conflicted files
>
> I can think of a few hackish methods to do this, involving manipulation
> of mergeinfo and other bad mojo, but I’d really rather not.
Wouldn't the option "ignore ancestry" when merging ignore the mergeinfo
and just do the merge?
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2394184
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-13 09:05:24 CEST