Just to throw out a possibly dumb idea, you might want this to remain
possible for read-only mirrors. So I have svn server X and somehow I
manage to see that all commits on X show up on server Y as well, in a
safe manner. So now clients can check out from server Y, which may be
a lot closer to them, but they can't commit to it, since it's set up
read-only. All commits must happen on X. So the user does some edits,
and when he's ready to commit, does an svn switch to X, then commits,
and switches back.
The unique identifier per collection idea may still work if the
migration of commits from X to Y preserves them, but a strict check of
"hey that's on a different server" won't.
This may not be a useful idea for how to mirror repositories, but I
had the thought, followed by another thought that I might should share
the first thought.
-wsv
On Friday, September 20, 2002, at 03:37 PM, Josef Wolf wrote:
> On Tue, Sep 17, 2002 at 09:57:31AM -0700, Greg Stein wrote:
>> On Tue, Sep 17, 2002 at 07:19:16AM -0500, Ben Collins-Sussman wrote:
>
>>> Think about it: there's no way that 'svn switch' knows that the two
>>> URLs are really the same repository, or same location. 'svn switch',
>>
>> 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.
>
> +1 on this. And I would suggest to make even more sanity checks. Just
> to give an example:
>
> $ svn co $REPO/trunk wc
> $ cd wc
> $ svn cp . $REPO/branches/1.0
> $ emacs src/bar.c
> $ svn sw $REPO/branches/1.0/foo
>
> I think every directory created by "svn mkdir" or "svn import" should
> get a uniq identifier. This identifier would be inherited when a
> directory is "svn mv"d or "snv cp"d. This way "svn switch" could check
> whether the target directory is related to the source directory and
> abort usage errors like the one above.
>
> --
> -- Josef Wolf -- jw@raven.inka.de --
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 21 00:53:47 2002