[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: David Glasser <glasser_at_davidglasser.net>
Date: Wed, 17 Sep 2008 10:07:24 -0400

On Wed, Sep 17, 2008 at 7:29 AM, Greg Stein <gstein_at_gmail.com> wrote:
> On Wed, Sep 17, 2008 at 3:34 AM, Vincent Lefevre <vincent+svn_at_vinc17.org> wrote:
>> On 2008-09-15 05:17:25 -0700, Greg Stein wrote:
>>> If it is renamed, then you've just "lost" your metadata. The metadata
>>> is tied to an absolute path.
>> An absolute path? This would be annoying because the path to my NFS
>> home depends on the machine from which I have access.
> If there are no .svn directories in your working copy, then it looks
> like any other directory. The only way for svn to know it's a working
> copy is to hold a reference to its absolute path.
> That said, we've also been discussing how to drop a unique identify
> into (say) .svn/wc-id at the root of your working copy. There are some
> potential issues with that, however. When svn sees the working copy at
> a new path, it won't necessarily know if it was simply moved or
> copied, and (thus) how to handle the metadata that it has recorded for
> that working copy.
> In your situation, you'd simply want to keep the metadata in the
> wcroot, rather than a centralized location. If all the data is in
> wcroot/.svn/, then svn will not worry about the absolute path at all.

As this thread has gone on, I think I've lost track of the motivation
for centralizing the metadata beyond just the working copy root. I
understand wanting to be able to (optionally) centralize and share the
blob-store (since file contents/etc are likely to be shared between
multiple working copies), but what is the gain of combining the actual
working copy metadata itself? (More than "you can control where it
sits", which you can also do by replacing the .svn directory with a


David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
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-17 16:07:35 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.