On Fri, May 08, 2009 at 02:12:30PM +0200, Bernhard Brunner wrote:
> I have the following use case:
>
> A project named 'Proj' contains some subdirectory, say 't'.
> Now I create a branch of this project, say 'ProjB', check it out and
> remove t, because its content won't contribute to the users of the
> branch and shouldn't be visible to them.
> I continue working on 'Proj' and occasionally merge it with 'ProjB' to
> keep the branch up to date.
> So far, this works fine and follows the usual work flow.
>
> However, every time I change something within 't', I will get a tree
> conflict that must be explicitly resolved, before I can commit the
> result of the merge. Although I understand that this is formally
> correct, it gets tedious over time. Also it is also hard to explain to
> coworkers (most of them having some experience with CVS), why they have
> to resolve a conflict for a non existing item. I tried adding 't' to the
> ignore property of 'ProjB', but this made things worse, because I still
> got the tree conflict, but could not resolve it anymore.
>
> From my point of view, it would be acceptable, if I got a tree conflict
> once, but then never again, since that conflict has been as resolved
> (after all the directory was removed just once). After all, one of the
> reasons to remove the directory (and some files) was that I don't want
> to merge stuff that is not needed within the branch anyway.
The client does not remember tree conflicts that have been marked
resolved. It just forgets about them. That's why you get this
problem over and over again.
> Does anyone know a way to handle this situation more elegantly?
Currently, we default to the safest way of doing things, and require
users to manually override this.
The best solution would be to implement a configurable policy that
specifies how to deal with tree conflicts of a certain nature,
optionally scoped to a given file or directory.
This would also help automated merging.
This idea has been discussed before as a possible improvement to
tree conflict handling, but no one has stepped up to do it yet.
You are certainly welcome to contribute :)
Stefan
Received on 2009-05-08 14:38:45 CEST