Date: Sun, 16 Mar 2003 16:21:26 -0700 From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Sean Chittenden <sean@chittenden.org>, Nate Williams <nate@yogotech.com>, Sergey Babkin <babkin@bellatlantic.net>, hackers@FreeBSD.ORG Subject: Re: making CVS more convenient Message-ID: <15989.1782.166458.477601@emerger.yogotech.com> In-Reply-To: <3E75010D.EEA8B4D@mindspring.com> References: <3E73DCF7.80490FA6@bellatlantic.net> <15988.49648.483313.383942@emerger.yogotech.com> <3E74CC37.DF83EE46@bellatlantic.net> <15988.52765.777500.37926@emerger.yogotech.com> <20030316195807.GH66903@perrin.int.nxad.com> <3E75010D.EEA8B4D@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > The corollary to that would be to teach cvs(1) to commit changes to > > the master repo that have been made to the local repo. Version number > > sync would be a problem, but it'd be really cool to be able to do > > that. With a branch mapping layer (RELENG_5_SEANC -> HEAD), people > > could actually get back into the habit of using CVS as a development > > tool instead of just a way of publishing finalized work. > > Nate's suggestion covers the version number issue... sort of. It > assumes that the patches will be approved for commit to the main > repo This is easy to get around, b/c if the commit doesn't happen successfully on the repo, then the commit fails, and as such it also won't also be committed to the local branch (the remote commit failed). > and it assumes that the main repo will not get tagged in > between. For *most* users, this is not a problem. My solution is for the developer. However, it's not intended to make the local cache a complete mirror of the remote repository. That is a whole 'nother project. :) > The main problem with that is pretty obvious, especially > around code-freeze/code-slush, but also for anyone without a commit > bit, or who is being "mentored", and so lacks the ability to "just > commit". Even during code-freeze, it does allow you to everything you *need* to do safely. If you attempt a commit and your local cache isn't up-to-date, then the commit will fail, and the user will have to re-sychronize their repository. Fortunately, this is a mostly rare occurance, especially if there are regular scheduled synchronization occurances (aka; nightly cron jobs). > A more minor problem is that it replaced the version conflict with a > "$FreeBSD$" conflict that CVSup has to ignore. See above. This is mostly a non-issue as long as the versions are kept up-to-date. No merges will be attempted what-so-ever, even if they would not necessarily cause conflicts. However, this is all a pipe-dream, although Sergey's work is making it less pie-in-the-sky. The other solution to the problem is the P4 route. Making things so darn effecient that there's little need to have a local mirror. Where this falls down is when the remote developer doesn't have a 24x7 connection to the main repository. From what I've been told ClearCase allows for 'mirrored read-only' repositories similar to what most of the open-source CVS developers have been doing with sup/CVSup for years, although it's nowhere near as effecient as CVSup at creating snapshots. 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?15989.1782.166458.477601>