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?
> 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; note that he mentioned IO being
the biggest slowdown here:
http://svn.collab.net/repos/svn/trunk/notes/wc-improvements
> >You can only make assumtions if you wrote the things; you make
> > assumtions on the format of the entries file (and other things) for the
> > plain and simple reason that svn wrote the file.
> >So if the upgrading routine of the format of the .svn dir makes sure he
> >actually _knows_ about the format file afterwards; then yes you can make
> >assumtions.
>
> The catch is that you can't make assumptions about the order of working
> copy directory accesses. It's entirely possible to have a path A/B/C,
> where A anc C are at version N, and B is at N+1.
Ehm; please take a little longer to reply so you have time to read my
response...
I'll repeat; write the upgrade-format-version code so you _do_ know. At
that point you can make assumtions. The how is explained below;
> >There are lots of ways to do this; if you find an old version in a
> > parent dir you upgrade it and upgrade all child dirs (which are listed
> > in each entries file) at the same time; and only when everything went
> > fine you note that in the format file. With this approuch only one
> > .svn/format needs to be read.
>
> How do you find an old version, except by reading he format (or
> equivalent) file?
Like I said; by reading the format file; the trick is to make sure the
entire repo has the same format version so there is only one in the repo to
read.
Its not like the format will change between each update and commit, right?
> >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? :-)
Ofcourse you need to first create an optimistic lock file and then you start
checking for subdirs / superdirs that have one.
Which is nothing new since thats already how you do it right now, or does
the current way of working suffer from race conditions?
--
Thomas Zander
- application/pgp-signature attachment: stored
Received on Sat May 7 23:09:26 2005