On Fri, May 08, 2009 at 03:43:13PM +0200, Bernhard Brunner wrote:
> >> 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.
> >
> I see...
> While I could personally live with that behavior, even if it is
> annoying, the really bad thing is that it breaks our existing scripts
> and basically prevents me from upgrading to SVN 1.6 on any machine that
> has to run such a script.
I'm starting to wonder if you could simply choose to leave the unused
directory in place on the branch and ignore it? If it's not modified
on the branch anyway it should always receive changes from trunk cleanly
and not be much of a bother.
You mentioned that the content of the directory should not be visible to
people working on the branch, but how important is this, really? Is it
important enough to justify the merging problems it creates, and is it
worth preventing an upgrade to 1.6? And note that svn rm won't protect the
directory from visibility by people working on the branch anyway because
they have access to the history of the branch, so you're probably using
a wrong solution to your problem already.
You could also move the offending directory somewhere else in the
repository, protect it and trunk properly using authz instead of svn rm,
and if necessary make it accessible in trunk again at its old place
using a directory external.
But before you jump into using authz, make sure to read
"Do You Really Need Path-Based Access Control?" in the svnbook:
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
And make sure to take a look at issue #3242:
http://subversion.tigris.org/issues/show_bug.cgi?id=3242
(tigris.org's web server seems to be down right now...)
If you really want to stick with your current approach I'm afraid you
will need to adjust those scripts that are breaking or stay stuck
with Subversion 1.5 forever. To fix the scripts, you could automate
something like "svn resolve --accept=working" on all affected items
if that produces the desired result.
If you can, I would really recommend to just leave the directory on
the branch for people to see and ignore. This is the simplest solution.
> Wouldn't it be rather simple to suppress or automatically resolve tree
> conflicts for ignored files/directories?
> Granted, this only works, if you never merge back from branch to trunk,
> but that's exactly the situation which we are facing.
> At least that seems quite intuitive to me. Implementation might be a
> different thing of course. Just an idea.
Making tree conflict detection depend on the presence of svn:ignore
properties in some way is not what svn:ignore properties have been
made for. svn:ignore properties deal with items that are not under
version control at all. They are just a nice way to stop Subversion
from warning you about unversioned files in the working copy.
I'd rather not see svn:ignore abused for dealing with tree conflicts,
because that implies that it suddenly has meaning for versioned items.
Especially if a better solution is known, like the already suggested
configurable tree conflict handling policy.
> Sometimes it would be rather helpful anyway to exclude certain items
> from a merge. I think this could be controlled in a similar way.
That idea opens yet another can of worms -- merge-tracking :)
Stefan
Received on 2009-05-08 18:34:42 CEST