On Sun, Feb 14, 2010 at 06:19:41PM -0500, Glenn Maynard wrote:
> On Sun, Feb 14, 2010 at 5:30 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > The WC holds the references to the pristine store.
> > So if the WC is deleted, so are references it has to the pristine store,
> > without doing anything special.
>
> How could a reference to "~/.subversion/shared/SHA" be stored in a way
> that a reference to it (presumably in a database somewhere)
> is removed,
This database is in the .svn dir at the WC root, so it gets deleted
along with the WC by the rm command.
> and the shared file deleted (if it's the final reference),
> when I rm -rf a WC?
As I said, I don't expect pristines to clean up themselves.
What if I rm -rf one WC and then checkout another, very similar one?
If the pristines from the first WC are still on disk, checkout performs
much better.
So I guess there will be a separate command to garbage collect the
pristine store. So the question of whether a final reference to
a pristine is being deleted is thus irrelevant at the time of deletion.
It will be similar to git, which also keeps growing its repository
until you finally decide to pack it.
> > The functionality you speak of happens to work because of the way the
> > 1.6 working copy format has been modeled on CVS. I'm not sure if
> > detaching subtrees from a working copy was a high priority design goal
> > to begin with, or if it was a side effect. I'd suspect the latter.
> > It is a bit contradictory to the "working copies are cheap and
> > disposable" mantra.
>
> It's a useful result of the design of both systems, whether or not it
> was an explicit design goal.
But if it's not a design goal, then there's no point in complaining
when the feature goes away. Either the feature is part of the design
or it isn't.
This feature might continue to exist in 1.8 or later, but as an explicit
part of the design. Or maybe the shared pristine store will make a
checkout of the subtree perform virtually as well as a local disk copy.
And then severing WCs won't bring any benefit over a fresh checkout
of a subtree of an existing WC.
> I don't understand the connection to "cheap and disposable", though.
I meant the assumption that working copies are relatively cheap to retrieve.
In this light, why sever an existing WC when you can cheaply check out
another working copy of the desired subtree? Of course, nothing beats
a local disk copy or move in terms of performance, but to get this performance
you currently need to use a "cheat" that happens to work because of a side
effect of the 1.6.x WC design.
I know the assumption that WCs are cheap is not always true in practice
since some folks have ridiculously large working copies. But a shared
pristine store will help those folks.
Stefan
Received on 2010-02-15 01:14:40 CET