You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Bernhard Brunner <br...@brudesy.de> on 2009/05/08 12:12:30 UTC
Tree conflicts when merging deleted directories or files
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.
Does anyone know a way to handle this situation more elegantly?
I already thought about moving 't' out of 'Proj' and creating an
external in its place, but since it is an integral part of the trunk
project, just not of the branch, this doesn't seem to be a very good
solution either.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2111597
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Tree conflicts when merging deleted directories or files
Posted by Stefan Sperling <st...@elego.de>.
On Fri, May 08, 2009 at 07:46:10PM +0200, Bernhard Brunner wrote:
> > 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.
> >
> You're right in principle. The problem in this special case is not so
> much a technical one but an organizational.
OK. Then you have to fix it somehow in your organisation :)
> > 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.
> >
> That's true of course. Nevertheless, I think the current behavior is
> quite strange:
> You get a tree conflict on the removed and ignored directory and cannot
> resolve it unless you remove svn:ignore for the affected item.
> That's not the way it should work, although I have no idea how to handle
> such a situation correctly.
Well, from svn's point of view, it's strange that you use svn:ignore
to tell it to ignore an item that is actually versioned.
I am not sure whether the svn:ignore design supports use cases like
that. It certainly wasn't invented for this kind of use case.
The title of the svnbook's chapter on svn:ignore explicitly
says what they should be used for: "Ignoring Unversioned Items"
http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.ignore.html
I don't know if we even have a defined behaviour when versioned
items are listed in svn:ignore. I would not be surprised to
find undefined behaviour.
> The problem simply arises from the fact that tree conflicts were
> introduced before the handling policy was fully in place.
Yes. Because we cannot do everything at the same time. It took
about a year to get tree conflicts to were they are now. We have to
make releases at some point. And to see whether a feature holds up
in real-world scenarios, we have to release it. It's not like any of
our users would trust us enough to run our trunk code in production
(unfortunately, IMO).
The feedback you are providing is exactly why we have released tree
conflicts as they are in 1.6. The feature is mature enough to work for
the general user base. I honestly expected about as much complaints
as there were about merge-tracking when 1.5 came out, but there are
remarkably few complaints coming in. Edge cases like your's is what
we are looking for now, and they will require either finding usable
workarounds, fine-tuning the design and implementation, or expanding
the tree-conflict feature set. I'm trying to find out which one of
those is most appropriate here, that's why I keep following up :)
> Although I
> like the idea of tree conflicts in general, it might have been a good
> idea to provide an update/merge option which simply doesn't generate any.
And (again), what about making your scripts do svn resolve --accept=working?
That would emulate the old behaviour, too.
> Be it good or bad, at least where I work quite a number of scripts (most
> of which still based on CVS) rely on the fact that a branch which
> contains removed items can be updated without problems. Until now,
> migration went rather smoothly and many things became simpler, but now I
> see problems creeping up.
Well, one user's feature is the other user's bug :(
For some people, merging without tree conflict detection is pure horror.
See this slide set:
http://www.subconf.de/fileadmin/PDF_Dateien/SubConf/SubConf_2008/Vortraege/Nico_Schellingerhout1.pdf
Note that this particular user has had a strong influence on the
tree conflict feature, to the point of providing support during the
design and implementation of tree conflict detection in Subversion,
and even going beyond that by creating their own open source wrapper
script providing features they need we cannot yet provide in the
Subversion core libraries:
http://trumerge.open.collab.net/files/documents/211/1822/DOCUMENTATION
You can do things like that, too.
If you really think that a switch that restores 1.5 behaviour by making
tree conflict flagging a no-op is a better solution than adjusting
the release staging process in your organisation, I will stubbornly
encourage you or someone in your team to take a shot at it, and give
you the hint that the guts are in libsvn_client/update-editor.c and
libsvn_wc/merge.c. Add the switch and work your way up from there
through two or three layers of API to the command line client and
you're done. See also http://subversion.tigris.org/hacking.html#patches
Regardless of whether you want to submit a patch or not, feel free to
file an issue pertaining to this command line switch, pointing to this
thread in the mailing list archives. Maybe others who are having the
same problem will find the issue and work on it.
As long as the switch isn't on by default, and there is a big red warning
sign in the help text for the option, making clear that the switch is
intended for people who still operate Subversion in "CVS mode" and
don't care about potential errors in merges because they don't rename
things anyway, I wouldn't see a problem with having it.
But keep in mind that there are many ways of solving organisational
problems that don't necessarily involve modifications to software :)
Stefan
Re: Tree conflicts when merging deleted directories or files
Posted by Bernhard Brunner <br...@brudesy.de>.
>> 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...)
>
No, I've already decided against this possibility. I don't want to mess
around with the server setup and its admins.
> 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.
>
You're right in principle. The problem in this special case is not so
much a technical one but an organizational. The resulting checkout goes
into a production environment where people don't have much in mind with
version control. Every change causes much questioning and paperwork.
That's the main reason, I want to keep the visible amount of change at a
minimum. There should have been an intermediate step, which performs the
checkout and afterwards distributes files as necessary, but alas! Well,
I think this is getting a bit OT ;)
[...]
> 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.
>
That's true of course. Nevertheless, I think the current behavior is
quite strange:
You get a tree conflict on the removed and ignored directory and cannot
resolve it unless you remove svn:ignore for the affected item.
That's not the way it should work, although I have no idea how to handle
such a situation correctly.
The problem simply arises from the fact that tree conflicts were
introduced before the handling policy was fully in place. Although I
like the idea of tree conflicts in general, it might have been a good
idea to provide an update/merge option which simply doesn't generate any.
Be it good or bad, at least where I work quite a number of scripts (most
of which still based on CVS) rely on the fact that a branch which
contains removed items can be updated without problems. Until now,
migration went rather smoothly and many things became simpler, but now I
see problems creeping up.
>
>> 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 :)
>
Right. A favorite of mine ;)
Bernhard
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2117268
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Tree conflicts when merging deleted directories or files
Posted by Stefan Sperling <st...@elego.de>.
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
Re: Tree conflicts when merging deleted directories or files
Posted by Bernhard Brunner <br...@brudesy.de>.
>> 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.
>
>> 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 :)
>
Sounds promising, but also seems to require quite some effort. Might
even be interesting. If I hadn't already enough work to do ;)
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.
Sometimes it would be rather helpful anyway to exclude certain items
from a merge. I think this could be controlled in a similar way.
Bernhard
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2113734
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Tree conflicts when merging deleted directories or files
Posted by Stefan Sperling <st...@elego.de>.
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