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

Re: Continuing to support older working copy formats

From: Ashod Nakashian <ashodnakashian_at_yahoo.com>
Date: Sun, 22 Apr 2012 14:07:25 -0700 (PDT)

----- Original Message -----

> From: Johan Corveleyn <jcorvel_at_gmail.com>
> To: Subversion Development <dev_at_subversion.apache.org>
> Cc:
> Sent: Sunday, April 22, 2012 11:20 PM
> Subject: Continuing to support older working copy formats
>
> Hi,
>
> Wouldn't it be great if svn could keep around code for handling older
> working copy formats, and for upgrading/downgrading working copies at
> will between a certain number of formats? Or like danielsh recently
> suggested during a discussion on users@ [1]: don't make format
> upgrades mandatory (like we do for FSFS formats), but keep the ability
> to read from and write to older formats?
>

Reading/writing older formats might be feasible given sufficient resources to implement/test/maintain the respective code, however, downgrading is just a completely different beast by any measure. Supporting downgrading should prove harder, and, I dare say, there is expectedly little incentive for the effort, which isn't trivial to start with. In fact, a case may be made that it's not worth the risk and resources.

As for reading/writing older formats, I think it's probably a good-to-have feature, but consider that any code warrants implied support and maintenance on our part. This added overhead for each old version (and the combination of upgrade/downgrade operations on them) will eventually take its toll on the project, again, with little ROI.

For my part, if I were to choose, I'd prefer putting more effort on improvements and requested features rather than extended support for old formats. And if downgrading is a most requested feature, then that's what we should triage next. But that's a big if right there.

Just my few cents,
Ash
Received on 2012-04-22 23:08:03 CEST

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.