Date: Sun, 16 Mar 2003 12:18:53 -0700 From: Nate Williams <nate@yogotech.com> To: Sergey Babkin <babkin@bellatlantic.net> Cc: Nate Williams <nate@yogotech.com>, hackers@FreeBSD.ORG Subject: Re: making CVS more convenient Message-ID: <15988.52765.777500.37926@emerger.yogotech.com> In-Reply-To: <3E74CC37.DF83EE46@bellatlantic.net> References: <3E73DCF7.80490FA6@bellatlantic.net> <15988.49648.483313.383942@emerger.yogotech.com> <3E74CC37.DF83EE46@bellatlantic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > The value specified in CVSROOTCACHE is the local path to the cache > > > repository. All the check-outs, updates, diffs etc. will be obtained > > > from there. All the check-ins, tagging etc. will go into the master > > > repository specified by CVSROOT. Naturally, to see these changes > > > in the cache repository, it needs to be updated by some outside > > > means such as CVSup or CTM. > > > > So, the cache doesn't automagically update itself when commits are done? > > This is less useful, since often-times after a commit has been done the > > user is still working in the same general area, so a 'cvs update' would > > now give the user older files since the read-only cache is not > > up-to-date, thus making it a requirement that everytime you make a > > commit, you also sychronize the cache. > > That's the plan for the next stage, provided that the first stage > goes well. I'm yet to play with CVSup and see if it can be > integrated there (as with system()) easily without making a lot > of changes to CVS itself. Otherwise I'm aftarid it's going to > be a large amount of work to duplicate this functionality :-( Another choice is to have the commit be also made to the 'cache' if and only if the remote (master) respository has accepted the commit. That way, the commit is made in both repositories using the same algorithm, so in essence they should be in sync. This saves the overhead of running a complete synchronization of all the files. And, you have a safe 'fallback' of mirroring the remote tree which should cleanup any problems you had, which will still be for any non-local modifications. > Yet another idea is to be able to make "local commits" with committing > them to the central remote repository later. I'd do the reverse, since the possibility of synchronization problems are a huge deal. Imagine if someone 'snuck' in and made a commit in the master tree after your local commit was made, but before 'later' occurred and your cache pushed it out to the master tree. If you only allow the commit if it can occur locally, you're ensuring that the cache can't get out of date with local changes. I tried something like the above (cause it was easier to implement), and it worked most of the time. However, the times it didn't work it was a royal pain in the *ss to cleanup and get the original commit back out. > Now I have to use RCS > locally for the temporary in-delevopment versions of file. Would > be nice to have a kind of a local branch which can be later committed > as a whole - in one commit per file, or by duplicating all the > intermediate versions with their messages. Agreed. The downside to the above method is that it requires network access to make a commit. However, it certainly simplifies the problem set. :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15988.52765.777500.37926>