On 1/17/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> but that's probably a question for the SQLite people. (And I've always
> thought that sharing working copies was a pretty odd thing to do; remote
> working copies, fine, but shared ones? Weird. I'd have no problem
> telling people that that's just not a supported arrangement).
Here's a use case at Apache that we rely on shared working copies: our
production websites are checked out to a group-writable directory, and
when people want to push the content live, they run 'svn up'. Anyone
in the group can run it at any time. Serving directly from SVN for
such a high-traffic site would be an issue; plus we have many vhosts -
which mod_dav_svn wouldn't play too well with. I'm sure we're not the
only people in the world doing that. (In Apache, we've always talked
about adding some automation to this to not need to do a 'svn up' and
hence have a shared WC, but we've never gotten around to it and
unlikely that we ever will.)
I chatted with Dave last night on IRC about some of these ideas, and
I'm generally +1 on his rough ideas. I don't see any problems with an
optional WC library for now - when we're ready to switch the default,
we can decide what to do then... My inviolate criteria are: multiple
users can share a WC, and the entire WC can be portable. So, Karl's
earlier suggestion of storing WC data in ~/.subversion or similar is a
non-starter for me (AIUI, this is how SVK treats checkouts).
I do wonder how this would impact TSVN or other GUI apps - how do they
know if a directory is under version control? Does it even trigger if
there isn't a .svn dir? Or, does it call some SVN APIs on every
window change? I'm sure we could work with them to make sure that we
don't screw them. I'd imagine for deep WCs, a GUI like TSVN might
constantly be walking up the directory path to see if a .svn directory
exists. I also don't know how well we'd handle excluded directories -
i.e. user doesn't check in a certain sub-directory - it'd be nice to
handle those efficiently as well without the time/walk penalties too.
(Think of SVN's svn-test-work dirs.) Doable, but would need some
thought, I think.
If we switch to an explicit severability model, I guess this means 2.0
to be on the safe side as to user expectations. I don't want to have
to explain that we silently took away something that users might have
been relying upon (largely because we're not creative enough to know
what they're doing with it) - perhaps a poll on users@ would be a good
thing? Explain it in a brief email and see if anyone is using this?
It'd be a slightly wider audience than dev@. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 17 16:31:17 2007