On 10/4/07, Mark Phippard <markphip@gmail.com> wrote:
> On 10/4/07, David Glasser <glasser@davidglasser.net> wrote:
> > On 10/4/07, David Glasser <glasser@davidglasser.net> wrote:
> > > On 10/3/07, Karl Fogel <kfogel@red-bean.com> wrote:
> > > > "Daniel L. Rall" <dlr@finemaltcoding.com> writes:
> > > > >> Hmmm, it seems init_adm() does take a 'depth' parameter, so we might
> > > > >> be able to swing this. I'll spend a few hours on it. If it's done by
> > > > >> the end of that, great; if not, I'll at least know whether doing it is
> > > > >> hard or easy.
> > > > >
> > > > > Don't bother. As painful as it is, we have to bump the format number.
> > > >
> > > > Sigh. I think I have to agree. There might be weird and surprising
> > > > behaviors if different subdirs in your working copy were to have
> > > > different format numbers. It just seems like a Bad Road to go down.
> > >
> > > Um, this is our working copy format. You know, the one where all the
> > > information is scattered randomly over a million directories... I'm
> > > pretty sure that the current upgrade code only upgrades one directory
> > > at a time anyway! So this is not as insane as you think.
> >
> > Having taken a look at the code, I am confident that it would be
> > pretty straightforward *technically* to bump the number to 9 but
> > preserve current format-8 working copies (or even never make format-9
> > working copies) until there is a non-infinite depth. Having
> > varied-version working copies should not be a technical problem at
> > all. Of course, it could be a social problem as Jack mentions in that
> > it makes the "line" between 1.4-compatible and 1.4-incompatible wcs a
> > little blurrier...
>
> Suppose some sub-folder has been bumped and a 1.4 client does a
> command from the root. What will happen?
It will error as soon as it tries to operate on the upgraded part. But
if it's operating on the rest of the wc, no problems will arise.
HTH,
Erik.
PS: 'Operate on' includes recursively locking from the root down for
whatever reason.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 4 20:43:17 2007