Thomas Zander wrote:
>Hi Branko,
>
>On Saturday 07 May 2005 22:45, Branko Čibej wrote:
>
>
>>Thomas Zander wrote:
>>
>>
>>>On Saturday 07 May 2005 20:47, Branko Čibej wrote:
>>>As I said; you read the entries files as normal, but you don't have to
>>>overwrite them for each dir if only the global version changed. Since
>>>the resulting xml would be exactly the same.
>>>
>>>
>>Whatever you'd gain during update by not recording the new directory
>>revision (on the assumption that it's the same as the old one), you'd
>>lose because your working copy would have a greater mix of revision
>>numbers, which means that the tree report sent to the server before the
>>commit would be larger. Exactly what this gain/loss ratio would be, I
>>wouldn't venture to guess, but I'm pretty sure it doesn't scale linearly
>>with WC size.
>>
>>
>Hmm? How do you gather that?
>If I do an update afterwards I'm sure that all dirs in that tree have the
>exact same version. (well; except if their sticky, but thats not what you
>seem to be talking about).
>So; how on earth would registering the revisions differently have any effect
>on the actual version numbers that those dirs have?
>Are we talking in completely different directions here?
>
>
Well, you /did/ say you didn't want to write the changed entries files
if the "shape" of the directory didn't change. So the directory revision
numbers in the entries file wouldn't be updated.
If that's not what you meant, then I am now thorougly confused.
>>Most of the time, yes, but disk access isn't the only slow part of an
>>update.
>>
>>
>>
>>>But, if you did the profiling part; I'd be happy to compare notes! :)
>>>
>>>
>>Oh no -- that's your job, part of the task of convincing us you're right.
>>:)
>>
>>
>
>Maybe you'd believe a co-developer better;
>
This is not about whom I believe, but about you proving that your
assertions are correct.
>>>If I type update in foo/bar then the root is bar. If I type update in
>>>foo/bar/baz; then the root is baz. Simple because thats already what
>>>you do now.
>>>
>>>
>>But what if you type "svn update foo/bar & svn update foo/bar/baz/qux"?
>>
>>
>
>Thats _exactly_ what I explained below! (now snipped)
>
>
>
>>Except of course for the potential race conditions, which can zap your
>>working copy.
>>
>>
>
>Ahh; yeah; I think my solution will be full of race conditions, why didn't I
>think of that when I wrote it.
>Wait; its not written yet; so you can still make sure it doesn't have any!
>Micro-bugfixing is not quite usefull at this stage; is it? :-)
>
>
If you're impying that resolving race conditions is micro-bugfixing,
then I strongly suggest you stop right there an do another think. I hope
you're not implying that.
>Ofcourse you need to first create an optimistic lock file and then you start
>checking for subdirs / superdirs that have one.
>
>
The result is that you actually have to traverse the whole subtree,
doing "stat"s instead of "creat"s, *and* you'd have to walk upwards, too
(which we currently don't do). That's an interesting approach to
optimisation. :)
>Which is nothing new since thats already how you do it right now, or does
>the current way of working suffer from race conditions?
>
>
I hope not. It should be free of race conditions.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 7 23:28:45 2005