[clue-admin] CVS Publishing Script

[grant johnson]

Do not do a -D in the export, it is TOO limiting.  Do the export by
tag!  Create a tag that means the current dev or test or production
site, then create more that denote each logical version, then you can
roll forward or back through version easily while keeping everything
in sync, and allowing you to release one thing, while working on
another in colaboration.


We do this via CVS with 150 developers on a multi-terabyte database
project with a 1GB+ CVS repostory.  i can help with the details if you
like.  It rocks.  Everyone can commit, but only release managers are
allowed to do the tags that cause the promotions, define the releases,
or assign releases to environments.  It is actually very easy to do.


On Thu, 16 Dec 2004 19:44:42 -0700, David Anselmi <anselmi at anselmi.us> wrote:
> Jed S. Baer wrote:
> [...]
> > This all works, except for the step of moving the symbolic link. I get no
> > errors from the 'ln -sf' command (or 'ls -s -f' either). But the link
> > stays put on the old directory. I can't figure out why this is.
> >
> > If I copy the ln command from the webserver output, and paste it to the
> > command line, it works.
> 
> On my system I can't reproduce what you describe as "working from the
> command line".
> 
> Here's what I tried:
> 
> ln -sf A WEBSITE ; ln -sf B WEBSITE
> 
> You'd expect this to make a symbolic link to directory A and then change
> it to point to directory B.  If A and B were regular files that's what
> it does.  But since they are directories the second command creates a
> link named B in the directory WEBSITE (which is actually A).  The man
> page seems clear enough if you realize the second command will
> dereference WEBSITE.
> 
> Looks like what you want is to add -n to avoid the dereference.
> 
> The nice thing about repointing the symlink is that it's atomic.  But
> I'm not sure that matters since old files may still be open.  So maybe
> just renaming directories is good enough (dunno though, I don't see any
> reason not to do it this way).  In that case though, I'd export straight
> to $NEWDIR.  What do you gain by exporting to /tmp and then tar'ing
> across (which could also be a cp it seems)?
> 
> Do you really want -D today in the export?  Seems like you can only do
> one update a day then.  Fine if you sync the web site from a daily cron
> job, but not what you want if you want your change up now.  You could
> use -r HEAD (or perhaps that's the default).  For a more formal system
> (with tags on the actual release code) you'd want to accept arbitrary -r
> arguments (probably not necessary here).
> 
> Finally, you might want to add some error checking/handling.  You have a
> comment that says "if successful, remove the tmp export" but you didn't
> actually check that anything succeded.
> 
> I use rsync on my web site (and I sync across the network out of a CVS
> working copy rather than a temp export, with some paranoia checks thrown
> in).  There's an rsync option to delete target files that don't exist in
> the source.  I guess that's a little overkill for this case, though
> rsync over ssh might give you better security than the .htaccess
> protected page we used to use (maybe you've already addressed that).
> 
> I'm interested in hearing other ideas.
> 
> Dave
> _______________________________________________
> CLUE-admin mailing list
> CLUE-admin at clue.denver.co.us
> http://clue.denver.co.us/mailman/listinfo/clue-admin
> 
>