[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: Branko Čibej <brane_at_xbc.nu>
Date: 2005-04-23 12:57:34 CEST

Greg Hudson wrote:

>Second, we generally don't have a good idea of why a file was copied.
>It could be for a rename, it could be to create a branch, it could be
>because the original was a template.
>
Which is exactly the reason why I've been saying that we need "svn
branch". "svn copy" simply does not have the same semantics. Likewise,
"svn rename" doesn't (yet) behave correctly.

I'd like to see the day when copy means copy, branch means branch, and
rename means rename. Therefore the order, IMO, should be:

1. Atomic renames.
2. "svn branch" (IIRC, only lazy copies actually create a branch without
creating a new node)
3. Merge tracking. IMNSHO 1. and 2. are absolute prerequisites for merge
tracking (or better merging, naming bikeshed). And there's no reason I
know of not to have merge tracking before 2.0.
4. ACLs in the filesystem
5. Server-side logging. Not just operation logging, either. Svnserve
falls down badly when compared to Apache because it doesn't produce any
logs at all.
6. Server->Client configuration transmission

Now, the fact is that these don't all cost the same, so it seems wrong
to focus on one feature in each release. Things like server-side
logging, for example, requre a fairly small initial effort but are an
ongoing concern afterwards, just like error messages. I propose we put
feature landing dates into the roadmap instead. Assuming a 3-month
release cycle, and a rough estimate of the complexity, i think the
following might be realistic:

1.3 (aug 2005): "svn branch". Start on atomic renames.
1.4 (jan 2006): Atomic renames. Start on merge tracking and ACLs.
1.5 (may 2006): Merge tracking, Server-side logging
1.6 (aug 2006): ACLs, Server->Client config

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 23 12:58:19 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.