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

Re: svn commit: rev 5361 - trunk/subversion/mod_dav_svn

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2003-03-17 22:32:10 CET

Branko Čibej <brane@xbc.nu> writes:
> Well, yes and no; this UUID would be completely hidden to anyone outside
> the repos/fs code.

Hmmm, good point. That does lower the losingness quite a bit.

> But we had this discussion before, and decided that we _need_ the uuids
> table in the long run. Ripping it out at this point would be sheer
> folly. What we _can_ do is decide that the copy in the FS is the master,
> and make sure that the on-disk copy is always in sync with the master.
> That shouldn't be hard to do.

Historical note: we did not "decide that we _need_ it" :-). We
decided that -- maybe, possibly -- the chances were slightly higher
that we would need it than not, and that since we didn't really know,
we might as well flip a mental coin and go with solution A. If you go
back to the archives, you won't see certainty on either side. We
really didn't have a strong reason to prefer either way.

The on-disk slave copy isn't so awful, I guess, as long as it is
clearly marked as not the master. It ain't pretty, but as long as
there are automated protections against its getting out of date (plus
maybe a comment right in the file, explaining that it is not the
master), it's not so bad.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 17 23:11:04 2003

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.