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