On Sat, Mar 20, 2010 at 10:10:06PM +0100, Johan Corveleyn wrote:
> Hi devs,
>
> I know a lot of you are mostly focused on wc-ng work right now (which
> is a good thing: focus is good, wc-ng is good). But I'd like to
> highlight two other important issues, which can IMHO be very confusing
> to users, and which I think should definitely be fixed by 1.7 (or if
> possible, sooner). I don't know if wc-ng makes fixing these easier,
> but they should be fixed none the less.
>
> * http://subversion.tigris.org/issues/show_bug.cgi?id=3525 - Locked
> file which is scheduled for delete causes tree conflict
This one is a real bug. It happens because the update editor driver
calls open_file() on the deleted path (possibly to set/query the lock
token?) and that function flags a tree conflict because it assumes
the editor driver will attempt to edit the file later.
I've set it's milestone to 1.7.0.
> * http://subversion.tigris.org/issues/show_bug.cgi?id=3526 - Commit of
> newly added file followed by move (or delete) of parent dir causes
> tree conflict
Sorry, but I think this issue should be closed as INVALID.
> The reason why they are so confusing is that you can get them all on
> your own, even if you're the only user of the repository, using only a
> single working copy. If you're the only one working in a particular
> area of the tree, it can be very disconcerting to suddenly be
> confronted with a tree conflict like this. Why on earth can I get
> conflicts (of whatever nature) if I'm the only guy making changes???
Because of mixed-revision working copies.
I know you understand the problem, and how it is caused by mixed revision
working copies (we've discussed this before and you explain it in the issue).
The only way to "fix" this self-inflicted tree conflict would
be to require an update of the *entire* working copy before any changes
can be committed. This is simply not possible to do because it is so
fundamentally different from the current, intended, behaviour.
Busy repositories would become very hard to work with.
As long as Subversion continues providing mixed-revision working
copies (possibly forever) it will not automatically bump the revision
of paths at commit time which aren't part of the commit.
> Ever since tree conflicts arrived, I try to explain to my users how
> they happen ("for instance, you edit a file, but in the meantime
> someone else committed a move, ..."). But the above issues don't fall
> into that category, so it's hard for me to maintain that svn is well
> designed software. And users don't really care about the mixed
> revision working copy (implementation detail).
It's not just an implementation detail. It's a feature :)
Users should care about it, in my opinion.
If you have users who really don't want to know about the details,
tell them to update their entire working copy before and after each
commit they make. That should avoid this problem, and is easy enough
to explain and understand.
Stefan
Received on 2010-03-20 22:44:49 CET