Yes, Unison does indeed seem like the correct tool for this job. It seems like I could just have a single command from each side, say "copsync" (cop being the CVS module name), and just remember to run it before leaving work. Maybe also schedule it for a cron run at midnight or something.
Thanks for the suggestions guys, they were helpful. The branch idea would be good if I was keeping it uncommitted for longer, but I don't think I really need the version control, and there are certainly ugly parts of being on a different branch to everyone else. Unison will just make sure that everything is sync'ed, and because CVS keeps it's working directory metadata hanging off the working directories, Unison will syncronise commits as well! Nice! Craig. Here are two excepts from the FAQ. Q : Has anybody tried to use Unison in conjunction with CVS in order to replicate a CVS repository for active development in more than one geographical location at the same time? Do you forsee any issues with trying to do such a thing, or do you have any tips as to how to get a setup like that working? A : Unison and CVS can be used together. The easiest way is to replicate your files with Unison but keep your CVS repository on just one machine (and do a commit on that machine after each time you synchronize with Unison, if files in that directory have changed). More complex schemes are also possible (e.g., using a remote CVS server and checking in from any host with one of the replicas), but should be used with care. In particular, if you use a remote CVS server, it is important that you do not tell Unison to ignore the files in the CVS subdirectory. Q : What are the differences between Unison and rsync? A : Rsync is a mirroring tool; Unison is a synchronizer. That is, rsync needs to be told ``this replica contains the true versions of all the files; please make the other replica look exactly the same.'' Unison is capable of recognizing updates in both replicas and deciding which way they should be propagated. Both Unison and rsync use the so-called ``rsync algorithm,'' by Andrew Tridgell and Paul Mackerras, for performing updates. This algorithm streamlines updates in small parts of large files by transferring only the parts that have changed. On Wed, 3 Dec 2003, Greg A. Woods wrote: > [ On Tuesday, December 2, 2003 at 18:04:35 (-0800), Mark D. Baushke wrote: ] > > Subject: Re: Problems with uncommitted working directories, from home and work. > > > > I suppose you could also consider the Unison File Synchronizer (see > > http://www.cis.upenn.edu/~bcpierce/unison/ for details) as a way to keep > > your checked out trees in a consistent state with one another. > > Yes, that's another good tool for the same job (and apparently it's more > portable to a wider variety of "client" systems than rsync is too). > > It might be a bit slower though -- IIRC it's written in an interpreted > language (which is also why it's somewhat more portable). > > _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
