On Sat, Mar 20, 2010 at 10:44 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Sat, Mar 20, 2010 at 10:10:06PM +0100, Johan Corveleyn wrote:
>>
>> * 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.
Thanks.
>
>> * 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.
I don't really agree that the TC problem is invalid (but maybe my
out-of-dateness digression is). See below.
>
>> 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.
You mean: "before you do any change", not "before any changes can be
committed", no? The problem happens at "svn mv"-time, not at commit
time.
> 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.
Ok, I think I'm beginning to understand that the out-of-dateness is
really unavoidable with the mixed-revision working copy.
But is there no way that this tree conflict can be avoided? That's the
real difficulty for users now. In this case the "incoming edit" is
just bumping the revision number of the directory. Everything else is
already up to date AFAICS. Or is this incorrect?
Maybe this is one of the TC cases for which an automatic resolution
can be defined and implemented for 1.7?
>> 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.
Yes, I know. But up until now this is totally unrealistic because
update is way too slow (windows, wc-1 locking, ... it takes over 4
minutes to perform an update of an average-size WC in our company on
an average client pc, even when there are no incoming changes; having
an SSD on the client machine brings this down to 45 seconds, which is
better but still a lot IMHO). Maybe with wc-ng this will become a more
realistic usage pattern...
Maybe a pragmatic way to avoid hitting this out-of-date + TC on
moving/renaming a directory is just to update the dir that you're
going to move before you move it. That's more or less manageable I
think, as long as you don't forget it.
Thanks.
Johan
Received on 2010-03-21 09:41:03 CET