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
Received on 2009-05-08 21:13:47 CEST