Ph. Marek wrote on Mon, 28 Apr 2008 at 10:26 +0200:
> On Montag, 28. April 2008, Daniel Shahaf wrote:
> > Ph. Marek wrote on Mon, 28 Apr 2008 at 09:51 +0200:
> > > On Montag, 28. April 2008, Daniel Shahaf wrote:
> > > > I am trying to prevent syncing an instance of a repository[1] to
> > > > itself. Is it possible to tell apart two instances that have the same
> > > > UUID?
> > > >
> > > > (Equality of UUIDs is a necessary but not sufficient condition for
> > > > identity of instances, and equality of URLs is sufficient but not
> > > > necessary.)
> > > >
> > > > [1] "An instance of", since in DAV mirroring, etc., there are actually
> > > > two "instances" of the same repository.
> > >
> > > Sounds to me like you need some second identity for each repository - not
> > > the subversion-client-UUID, but another real-repository-UUID :-)
> >
> > Exactly.
> >
> > > How about a revprop on r0? Seems to be the easiest, and most compatible,
> > > place for that.
> > >
> > > Set it if it doesn't exist; then query the other repository; if it's the
> > > same there, it's the same repository.
> >
> > And if the revprop exists when the master repository is duplicated?
> > (e.g. if there are two mirror sites.) One could make 'svnadmin dump'
> > and 'svnsync' ignore the new property, but some people might tar or
> > rsync their master when they create the mirror.
> You're right, that's a problem.
>
> Hmmm ... it seems that this is similar to the problem "on which harddisk
> sector is that block" (that bootloaders need solved), when they go through
> some intermediate layers - device mapper, raid, etc.
>
> So there should possibly be some function that returns something like
> MD5(hostname . "\0" . absolute path to the repository)
> which gets passed down to the *real* repository filesystem layers, and
> answered *only* from them ...
>
> Then you could still have a problem if the repository is on a NAS, and gets
> mounted by two machines - one for http, one for svn+ssh ...
>
>
> Thinking along this lines I get a recursion - you need some value *for the
> repository*, that doesn't get transferred *with* the repository ...
>
Yes, that's the problem. :)
> So maybe some lookup table repos-UUID to real-ID, stored in some completely
> different location - like /var/spool? But if you change the machine, you'd
> like to keep it the same again ....
>
Maybe store the real-id in the repository's parent directory? (In
/foo/r.id for repos in /foo/r/.) That way it's easy to transfer it with
the repository, but not unintentionally; and different machines mounting
the same repos-instance would share the value.
(Has this been suggested before? It sounds a bit familiar)
>
> Don't know what's best - I think you've got a problem :-)
> - On one side you'll have to transfer that *with* the repository, but
> - on the other side you don't want to transfer it.
>
If the value doesn't transfer with the repository, then (1) mounting
from ™2 machines needs to be addressed; (2) If we also save the master's
id in the mirror (like we save master's UUID), then when the svnsync
master repository is moved to a different server all repositories that
mirror it must be manually told to expect the master's new instance-id.
> So, as conclusion - maybe take the revprop, and give an easy command "svnsync
> new-repos-ID" or something like that, that can be run after the initial
> rsync.
>
If the value transfers with the repository, then when a repository is
duplicated the second copy needs to have its value changed. (Only one
place needs manual tweaking, as opposed to all mirrors requiring
tweaking in the previous option.) I guess this option is better.
>
>
> Regards,
>
> Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-28 19:31:21 CEST