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

Re: what is svn 2.0? (was: Re: Another working copy library)

From: Martin Tomes <lists_at_tomes.org>
Date: 2007-02-02 10:23:59 CET

Ben Collins-Sussman wrote:
> On 2/1/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>> Ben Collins-Sussman wrote:
>> > On 1/30/07, Greg Stein <gstein@lyra.org> wrote:
>> >
>> >> And FWIW, I am very, very strongly against any notion of 2.0.
>> >> Personally, I see it as a failure in creativity. Shooting for 2.0 is a
>> >> shortcut.
>> >
>> > I agree that if we define 2.0 to mean "break all compatibility,
>> > everywhere", then yes... it will be a huge PITA for users. But
>> > presumably, there's some big net gain that the users get in exchange
>> > for their forced-upgrade pain, no? Isn't that sort of the point.
>> >
>> > While I agree with your sentiment above, it also looks like an excuse
>> > to never, ever, ever release 2.0. Your argument above could apply to
>> > pretty much every radical feature or design-change that ever gets
>> > proposed in the future, couldn't it?
>> >
>> > So I'm curious, Greg -- in your mind, what *would* justify a 2.0?
>> I've always kinda thought of "2.0" as the point where we finally say
>> two things:
>> * we've had it with duct-taping features onto our existing repository
>> backends, and so we're ready to start clean with them, sans schema
>> compatibility concerns.
>> * it's time to really drop our deprecated APIs and reset our function
>> version counters (s/svn_client_commit43/svn_client_commit/).
> What I'm trying to say: if 2.0 is going to be a huge pain for users to
> upgrade to ("you must upgrade all servers AND all clients! you must
> dump and reload!"), then we need to give them a really good motivation
> to go through all that. We have to offer them insanely amazing new
> features. Our press release for 2.0 cannot read, "Subversion 2.0:
> same as svn 1.7, but um... cleaner on the inside..."

One feature which would require database changes is knowing where
something has been copied to. Our users really miss the ability to look
at the history of a file and see where it was branched and tagged. This
alone would make us upgrade to 2.0.

Martin Tomes
echo 'martin at tomes x org x uk'\
  | sed -e 's/ x /\./g' -e 's/ at /@/'
Visit http://www.subversionary.org/
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 2 10:44:43 2007

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