[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking: repos upgrades?

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2004-11-20 04:20:36 CET

kfogel@collab.net wrote:
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
>>Umm, I was under the impression that we only supported downgrading to
>>an earlier patch release, not an earlier minor release... Correct me
>>if I'm wrong...
> I took a look in HACKING, and it's unclear on this point:
> > 2. Working copy and repository formats are backward- and
> > forward-compatible for all patch releases in the same minor
> > series. They are backward-compatible for all minor releases in
> > the same major series; however, a minor release is allowed to make
> > a working copy or repository that doesn't work with previous minor
> > releases, where "make" could mean "upgrade" as well as "create".
> The phrase "They are backward-compatible for all minor releases in the
> same major series" seems to indicated that they're, well, backward
> compatible for all minor releases in the same major series.
> But then the next phrase carves out an exception so huge as to
> practically eliminate the original rule. (I think I wrote this
> language, too, sigh.)
> In this particular case, we should be compatible if we can -- and it's
> easy to be compatible, so the question is easily resolved.
> But I wonder what the heck that language in HACKING really means?

I always assumed the 'backwards and forwards compatible' wording meant
something similar for working copy and repos format as it did for adding
functions. We can add a function in a new minor rev because we don't
support using code linked against that with an earlier version of the
libraries. Since we don't allow you to roll back in that case, I had
assumed we didn't have to allow it with working copies and repositories.
  Otherwise it seems like we can never bump a repository or working copy
format in 1.x, which seems kind of extreme to me.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 20 04:22:20 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.