[squeak-dev] [ANN] Monticello 2.0.20

Norbert Hartl norbert at hartl.name
Thu Aug 14 11:20:46 UTC 2008


On Wed, 2008-08-13 at 23:39 -0700, Avi Bryant wrote:
> On Wed, Aug 13, 2008 at 11:16 PM, Lukas Renggli <renggli at gmail.com> wrote:
> >> Here's a strategy that I think would work to allow networked
> >>  collaboration with MC2 in its current state.  Colin, let me know if
> >>  I'm making any faulty assumptions here or misremembering how MC2
> >>  works.
> >
> > Ok, that makes sense for a company. What about projects like Seaside
> > or OB where there are numerous developers that frequently change?
> 
> Managing the client side of that is easy: the image needs to know to
> look for new .mcr files in a certain directory and add them
> automatically as read-only repositories.  The rsync script needs to
> look for these on the server and download them automatically.
> 
> As for managing the server, well, you could certainly add a unix
> account for each developer and set the permissions on the files
> appropriately so that they could only write to their own .mcr.  The
> one thing this doesn't account for at all is anonymous commits...
> 
If you have a linux server you can set the sticky flag on a directory
which serves this purpose. Do chmod ug+rwx [dir] && chmod o+rwt [dir]
than everybody can create files but anybody is only allowed to write
or delete his own files. The most prominent example for this is /tmp

> > A related question is if there is anything in place that prevents .mcr
> > files from corruption when are accessed concurrently. I imagine that
> > you could keep the repository files on a shared drive somewhere.
> 
> I think this should basically work, as long as two people aren't
> committing at precisely the same time.  Even if they do, it might
> still work, I just don't remember if it's guaranteed :)

Yes it is. Pushing a file to the server means that the rsync server 
creates a temporary file (watch for dot files while syncing) and
moves them afterwards. That means files are only visibile after the
have been uploaded completely. A move is atomic in this situation
and prevents problems while overwriting a file through sync. 

Norbert




More information about the Squeak-dev mailing list