[ic] Risks of websites served from Subversion or CVS checkouts

[Gert van der Spoel]

> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org [mailto:interchange-
> users-bounces at icdevgroup.org] On Behalf Of Jon Jensen
> Sent: woensdag 20 augustus 2008 18:04
> To: interchange-users at icdevgroup.org
> Subject: Re: [ic] Risks of websites served from Subversion or CVS
> checkouts
> 
> On Wed, 20 Aug 2008, Rick Bragg wrote:
> 
> > Another benefit to unison is you can still vi right on the server at
> > will! (great in the field with a client!) then just sync up with
> unison
> > from anywhere to bring the live site back to the repository!
> 
> That is one of the reasons I find using a version control checkout in
> production to be so great. (Especially a decent version control system
> such as Git.) You can do git status, git diff, etc. to see what has
> changed in production, with or without your knowledge, and deal with
> it.
> You have the whole change history at your fingertips.
> 
> Peter wrote:
> 
> > Because I've found that CVS updates don't always go smoothly.  You
> get
> > bad connections, corrupted files, conflicts, I've had times where
> I've
> > had to delete the entire repository and check it out again anew.  I
> > can't speak for SVN or other systems, though.  I just don't want to
> have
> > to be dealing with a problem with an update on a live site.
> 
> I can understand that, but unless you're having such catastrophic
> failures
> regularly, I'd say that you have every bit as much a chance, if not
> more,
> of massive blowout in production using rsync or unison.
> 
> I've never seen such a problem, but whether using CVS, Subversion, Git,
> or
> others, there are ways to see danger ahead and protect yourself against
> it. Especially with a distributed version control system reverting the
> entire tree quickly is quite reasonable, whereas with CVS it could be
> slow
> and painful.
> 

My usual tactics for this:
- cvs tag  on dev
- auto sync to production
- cvs checkout xxx 
- change over symlink to the new version
- if it blows up, change back the symlink

Of course you'd have to get everything from cvs and you do not need to keep
a stack of logs or accumulated data in your tree ...
All these are depending on the type of projects etc ... Even if some data
would need to stay you could write a script to pull that data out of the
other tree again etc ... 

But I'm going off track by now :)
CU,


Gert