Date: Fri, 26 Sep 1997 03:52:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: tlambert@primenet.com, mike@smith.net.au, grog@lemis.com, hackers@FreeBSD.ORG Subject: Re: How do I check out a snapshot? Message-ID: <199709260352.UAA29332@usr05.primenet.com> In-Reply-To: <199709260329.MAA00428@word.smith.net.au> from "Mike Smith" at Sep 26, 97 12:59:27 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > You don't. Due to the nature of the distributed CVS repository, there > > > is a window where even the exact time of checkout for the snapshot > > > build might leave you out of sync. The only way around this would be > > > for the snap to be built from a tree directly checked out from the > > > master repository. Jordan does this for the for-CDROM versions, I > > > think. > > > > This is not due to the nature of the CVS repository; this is due to the > > way it is being used. We've had the discussion about "how to use it > > to close the window" before. Enforcing reader/writer locks by making > > the repository group writable and the locking program SGID the caller > > into the group would fix the problem, pronto. > > No, it wouldn't. Why not? If the main CVS repository can't be non-atomically updated, and the CVSup for the CVS mirrors had to acquire a reader lock to do the mirroring so they can't be non-atomically mirrored from the main tree, and the user CVSup's had to acquire a reader lock to pull from the mirrors so a local tree can't be non-atomically mirrored by the users... then there is no such thing as an out of sync CVS tree. If you are worried about keeping regionally seperate builds in sync, you just pick a snap date sufficiently far in the past that it spans the propagation delay for the mirroring between you and the master repository. > Closer would be to claim the "checkout" time for a remotely-built SNAP > matched the CVSup scan from which the remote repo was last updated, but > unfortunately there isn't any such thing. If *all* readers had to get a lock, including the CVSup for the remote repository, then there would be. You could build it into the daemon to assert a reader lock on where you are mirroring from, and build it into the client to assert a writer lock on where you are mirroring to. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709260352.UAA29332>