Re: [Screem-devel] Screem, CVS and multi-developer work

[Joe O. <jo...@or...>]

Here are my thoughts on the two problems:

1) How to ensure mutual exclusion over updates to the remote site... no
two developers can update the site at the same time.

2) How/where to store the sitecopy "stored state" file.

Solutions to problem 1:

a) One solution is to not implement any mechanism and leave it to
developer policy. i.e. pop up a dialog box before updating a
multi-developer site saying "Hey, make sure no-body else is updating
before you do this".

b) Let any developer do updates, and manipulate the remote site somehow
to indicate whether it is "locked" for update or not.

c) Let any developer do updates, and manipulate the local CVS copy of
the site somehow to indicate whether it is "locked" for update or not.

d) Appoint a single user as "official maintainer", and only let that
user do updates.

e) More fine-grained version of (d): delegate responsibility for
updating sites on a per-directory basis, and appoint certain developers
"official maintainer" for each directory.  i.e.  "Jim maintains
directory Foo"  "Bob maintains directory Bar". Then implement mechanism
so that Jim can't update directory Bar, and Bob can't update directory
Foo. This means splitting each Screem site down into separate "sitecopy"
sites: quite complex probably.

I would rule out (b): FTP does not support locking. I think trying to
add on locking using files or something is going to be an unreliable
hack. (WebDAV can do locking properly, but you want to do this for
FTP-maintained sites too I presume)

(c) sounds best to me if you can find a way to lock files properly via
CVS. (Per David's advice, I checked the info pages, and they say stuff
about 'cvs admin -l' which is supposed to do locking).

Otherwise, (a), (d) or (e) depending on how much work you want to do :)

On to problem 2, solutions as we've already covered:

a) Store it in ~/.sitecopy/.
b) Store it on the remote server
c) Store it in the CVS repository

(a) Limits the maintainer to their own box (if ~/ is not a shared NFS
mount etc), but nice easy and simple.

I think (b) is bad because it adds the overhead of going and downloading
the file every time you want to use it. Only talking in terms of 10's of
Kb's here for small sites, but these could get quite big for large
sites. (especially with the XML sitecopy-0.9+ files). And more
importantly, you have the worry that someone will delete the file by
mistake from the server.

(c) means you are keeping reduntant version history but developers can
move around between machines if they like, so gets my vote if (a) is not
good enough.

Hope these ramblings are of use... ;)

Regards,

joe