CVS

Edward Glowacki glowack2@msu.edu
Wed, 27 Jun 2001 16:52:16 -0400


Quoted from Ben Pfaff on Wed, Jun 27, 2001 at 04:40:22PM -0400:
> Edward Glowacki <glowack2@msu.edu> writes:
> 
> [...safety issues...]
> 
> > With CVS, isn't it pretty standard to do a cvs update then a cvs
> > commit?  That syncs both directions and makes sense.  With the rest
> > of it, perhaps it makes sense to have no default direction and make
> > the user explicitely declare which direction the operation will
> > go.
> 
> Yeah, CVS is pretty safe that way.  But you still run into
> situations where it can't do the merge automatically and you have
> to go into the resulting files and fix it.  (But it'll warn you
> about it and keep backups of the unmerged version.)

In that case, esync should tell you what happened and perhaps
make it easier to fix (allow you to start up an editor with the
file automatically or something maybe).  

My next challenge is to figure out how to do this modularly enough
so that you can add additional backends that might be foreign enough
to actually work differently.  rsync and CVS are pretty similar as
far as their capabilities and the fact that you can do something
like setup a module config where "QUIET=--quiet" (for rsync), but
what if to make it quiet you need to do something like 

"command >>/tmp/logfile" 

or something strange like that, how do you specify that in a config
file that expects variables?  I suppose you could make both ways
an option in the program and just choose which one to use when you
write the module, but what about all the other features that might
not be so easy to fix, like maybe a program that has to read the
username from STDIN?


-- 
Edward Glowacki				glowack2@msu.edu
GLLUG Peon  				http://www.gllug.org
Imagination is the one weapon in the war against reality.
                -- Jules de Gaultier