[Making this a general reply to the thread]
So far, I see cautious approval for this proposal on the thread. I
like that. That's cool, and I think I will start work on a design and
implementation as soon as my free time permits (which should by
mid-february).
Addressing the issues that have been raised now.
The first is that this is a 2.0 feature. I disagree for several reasons.
First of all, if it wasn't clear in my initial mail and followups, I
intend libsvn_wc_sqlite to follow the API that libsvn_wc has. There
may be a few new functions required (for example the call to sever a
subtree from the wc), and possibly some changes to the libsvn_wc API,
which would have to be backwards-compatible changes. However, as
noted, some of the semantics that some users have come to rely on
(known location of text-bases, using .svn as the basis for knowing if
a directory is under version control...) would be broken by
libsvn_wc_sqlite, which is why it cannot entirely replace libsvn_wc
before 2.0.
That, in my opinion, is not a strong enough reason to push off
addressing wc issues until 2.0. For that matter, we still don't know
exactly what we want and don't want in 2.0, nor when we will start
working on it. I am not prepared to put this off indefinitely until
the hypothetical time where we decide that we've had it with 1.x. That
watershed moment isn't clearly defined enough for me to rely on it.
Because I think that it does address real issues that have come up
with libsvn_wc, I think it should be implemented sooner rather than
pushed off to an uncertain future. As it has been noted, because some
of the internal behavior people have come to expect from libsvn_wc,
libsvn_wc_sqlite would break their expectations. That is why I want it
to be a separate implementation that can be selected at runtime.
Either you stay with libsvn_wc for your checkouts and keep existing
semantics, or you use libsvn_wc_sqlite and must adapt to the new
implicit promises it makes. Until we break compatibility for good in
2.0, you have a choice of staying with the known, or going with the
new.
IOW, I think this is as much a compatibility break as FSFS was for BDB
backend users, because the implicit promises that you could use BDB
tools to mess with the filesystem went away. People have the choice
whether or not to switch, and can make an informed decision based on
the various tradeoffs.
Which brings me to the maintenance burden issue that was raised. As I
have said, I am willing to put changesets where my mouth is and make
this happen. It seems a few other people are also willing to help out
doing this. I am very much against needless maintenance burdens, but I
believe that in this case the extra code is really, really worth it.
As much as maintaining ra_dav and ra_svn to cater for two different
sets of user constraints. And defaulting to use libsvn_wc will keep
users safe from shifting semantics until they decide to go there.
Regarding the proposed storage mechanism: I'm with Justin on the not
storing anything outside the working copy by default. I like my
self-contained working copies that I can delete without "detaching"
them or some such nonsense. However, there are cases where storing the
working copy metadata elsewhere could be useful (off the top of my
head, put the metadata and text-bases on a local drive, but keep the
source in an nfs homedir). This doesn't require complex designs, as it
can be achieved trivially by symlinking .svn to somewhere else. We can
even support it during a checkout if you balk at the extra commands
needed to shuffle stuff around, and I'm sure a change that also
supports using win32 shortcuts or what have you could be figured out
for the same end result.
I think that's about as far as I care to go for movable metadata
stores. I don't care about sharing metadata (other than text-bases,
which is a separate issue IMO) between working copies, it just
complicates the design for no net improvement that I can see. If you
want stuff in ~/.subversion, then put the metadata there and symlink,
and you're golden.
Finally, regarding `svn edit`. After thinking about it some more, it's
true that this feature is somewhat a separate issue to that of
revamping the working copy.
However, a Malcolm pointed out, it should be considered in the design,
so that it can be done later. There will already be a big improvement
coming from being able to run a couple of select statements through
sqlite, rather than locking and reading N different files all over the
place, but a crawl is still a lot of calls to readdir and stat, which
become non-negligeable in some cases (like a working copy on a
slightly slow nfs mount, where that translates almost directly into
RPC overhead).
However, I think that libsvn_wc_sqlite with tree crawls would still be
a huge improvement over plain libsvn_wc, even without using an
explicit edit operation to kill them off entirely. So, scratch
implementing `svn edit` for now, but keep it in mind when designing.
I'll start drawing up a more detailed design tonight, to flesh out the
general ideas.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 17 21:46:03 2007