> > 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
