On Tue, Sep 17, 2002 at 12:05:27PM -0500, email@example.com wrote:
> Greg Stein <firstname.lastname@example.org> writes:
> > It *could*, and we need it to.
> > Think about it: if you switch to a *different* repository, then you could
> > completely hose your WC (w.r.t repository) and commit total crap.
> > The answer is to add in what we've talked about for a while: a canonical
> > name for a repository. Since the repository itself passes that out, it will
> > be the same no matter how you access the repos (via proxies, different
> > hostnames, etc).
> It'd be pretty easy to have svn_fs_create_berkeley generate a GUID and
> store it as a property on revision 0 of the filesystem. Not that I'm
> suggesting that as the way to do this, of course. Just a thought.
Ah. Interesting thought.
Just a bit ago, I realized something about our previous thinking, tho. We
had thought to use the "base URL" as the canonical repos name. We even
considered using it as a true base and just remembering relative paths from
But that won't work(!) Consider mbk's case. The base URL changes based on
where he is working from. Thus, we need to keep the canon-name truly
separate from the URL used to access the repos.
This satisfies my theoretical-geek hat about not using the URL for the name
(we had this debate a while ago, and I admitted that I didn't have a good
reason for *not* using the URL other than a theoretical cleanliness; seems
like we have an actual use case now :-)
Given the need to avoid using a URL, then I like your idea for a GUID. That
definitely beats out the case where a (single-purpose) URL is composed of
the canonical server name; if you move the repos, then the canon name
changes and WCs break. Using a GUID prevents that.
Of course, a GUID also means that if you duplicate a repository, then you
could be in trouble. But a script to "rename" a repos would be cake.
I would suggest the GUID goes into the repository structure itself, rather
than a property on rev 0. But I'm only -0 on using the property.
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Sep 17 19:48:43 2002