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

Re: Medium-term roadmap: 1.3, 1.4, 1.5.

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-04-23 02:01:27 CEST

John Szakmeister <john@szakmeister.net> writes:

> On Friday 22 April 2005 17:31, David Summers wrote:
>> On Fri, 22 Apr 2005 kfogel@collab.net wrote:
>> > 1.3: Server->client configuration transmission.
>> >
>> > 1.4: Operation logging.
>> >
>> > 1.5: TBD, see below
>> >
>> > I'd really like to see atomic
>> > renames (issue #898 and possibly #895) tackled here, partly
>> > because that seems a prerequisite for any merge-tracking
>> > features (which is a whole other topic), and partly because

I don't really see why atomic renames are a prerequisite for merge
tracking. Atomic rename makes it easier to track renames, but copy
with history will still exist as a valid operation and merge tracking
is going to have to handle that as well. We could implement merge
tracking without atomic renames. I suppose the pitfall would be that
when atomic rename is introduced it might not fit into the mechanism
used to implement merge tracking, is that a serious worry?

>> > atomic renames are desirable in their own right.
>> >
>> > Atomic renames will require some discussions, see issue #898
>> > for the gory details. My guess is that it wouldn't force a
>> > schema change, though, and therefore could be done before 2.0.
>> > But maybe there are more important things our users are
>> > clamoring for? Any thoughts?
>>
>> Personally, I would rank them:
>>
>> 1.3 Atomic Renames
>>
>> 1.4 Server->Client configuration transmission
>>
>> 1.5 Operation Logging
>>
>> ...but then I haven't been involved with Subversion coding, it is just
>> my wish list comes out in that order. :-)
>
> I'd rank them the same as you David. I'd really like to see the atomic
> renames taken care of.

Are atomic renames really that attractive, or is merge tracking what
you really want?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 23 02:02:16 2005

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.