Stefan Sperling <stsp_at_elego.de> writes:
> Why does TSVN do this?
I've never used TSVN or looked at the code. TSVN works by letting the
user explicitly select the items to be committed, it's a Windows
explorer extention, so non-recursive commits are a natural fit. TSVN
also wants to know exactly which items will get committed.
> But you're still solving the problem in terms of wc-1. Maybe in a
> more optimal fashion, but that does not matter, because wc-1 is
> slated for replacement anyway. Any wc-1 solution is going to be
> obsolete in a few weeks (hopefully) or months (more likely).
I don't know how WC-NG will work either. I guess there will be some
sort of open function that does it's own optimised search for a root
and then returns a DB handle. The commit code could sort the commit
targets putting targets with fewer components first. For each target
it would query the list of DB handles to determine if the target was
covered and if not then open a further handle. You end up with a list
of handles without ever explicitly query the root. I'm suggesting you
do something similar using access batons.
Suppose you have a wc:
root1/
foo/
bar/
zig/
zag/
If you "commit root1/foo/bar root1/zig/zag" the current code opens a
single set of access batons rooted at root1. I'm suggesting you
change the code so that it opens multiple sets of access batons, one
for bar and one for zag. Once you have done that you get multiple
working copies for free: "commit root1/foo/bar root2/zig/zag" doesn't
care that root1 and root2 are different.
I haven't thought about this for very long so I could well have missed
something that means this won't work (for instance the exact order in
which you open the access batons could be tricky). I'm not going to
stop you or HuiHang pursuing your current approach, it's just not the
way I would tackle it.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2365650
Received on 2009-06-26 13:42:24 CEST