[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Base text files, re: IRC chat

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 15 Sep 2008 19:43:25 +0200

On Mon, Sep 15, 2008 at 01:10:14PM -0400, Karl Fogel wrote:
> Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> > Karl Fogel wrote on Mon, 15 Sep 2008 at 12:18 -0400:
> >> 1. The metadata knows where the working copy/copies live, by absolute
> >> path, as Greg says.
> >>
> >> 2. If you plain mv or cp a working copy, it stops working, BUT...
> >>
> >> 3. ...the error message from Subversion points out that the working
> >> copy may have been mv'd or cp'd, and offers a command to
> >> "re-register" it with the metadata store. This command is the
> >> metadata store's chance to clean up its reference counts
> >> w.r.t. that working copy.
> >
> > ... and also offers another command to un-register the previous location.
> I was thinking the same command would do both. That is, it would gather
> all the knowledge it could, from inspection and (perhaps) from the user,
> and DTRT.
> > And a command to list all WCs it knows about, maybe (so you can figure out
> > what needs to be unregistered).
> Urgk. Well, let's see if we really need that one first.

I fail to see what's wrong with a mandatory .svn at the root of
a working copy pointing to a meta data store to handle the
moved-working-copy use case.

I'd say manual user intervention should only be required if the
working copy was moved / copied, *and* the .svn directory in the
root of a working copy does not point to a valid metadata store.

For that case, only, the above plan sounds fine to me. But why make
life difficult for users if we can simply equip the working copy
with the necessary information it needs after having been moved?


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-15 19:43:48 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.