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

Re: [PROPOSAL 2]: Medium-term roadmap: 1.3, 1.4, 1.5.

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2005-05-03 10:34:10 CEST

On 30 Apr 2005 13:02:52 -0500, kfogel@collab.net <kfogel@collab.net> wrote:
> Looking over the responses to the roadmap proposal, I think they can
> mostly be summarized as: "Do atomic renames sooner!" :-)
> I feel strongly that trying to put "atomic renames" all in one
> milestone would be a mistake. As even the preliminary discussions
> have shown, it is not a trivial problem.
> The key (ironically enough, I guess) is to break atomic renames up
> into discrete subtasks as much as we can. Fortunately, there's an
> obvious place to start: implement atomic renames in the repository.
> We wouldn't worry about the working copy at first. It would still
> receive renames as it currently does, and the only gateway to the new
> functionality would be 'svn mv URL1 URL2'. But it would be an
> important first step and -- obviously, IMHO -- a prerequisite for
> further atomic rename functionality.
> (This is essentially what issue #898 is now, I think, although #898
> did not start out that way.)
> So below is a new proposal, similar to the previous one, but starting
> the renames work much sooner -- the first piece would happen in 1.3.

What you see here is a often requested feature which IMO comes from a
much larger issue. I think we should do an interim release to clean
out the issue tracker. No glorious new features, just bugfixes. This
release should address the rename problem, schedule-add-with-history
and a few others which can seriously mess up day-to-day work with svn.
 Surely, if 1.3 were to be that release, it will include neon 0.25

What do you think?



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 3 10:35:12 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.