Date: Sun, 16 Mar 2003 14:56:13 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Sean Chittenden <sean@chittenden.org> Cc: Nate Williams <nate@yogotech.com>, Sergey Babkin <babkin@bellatlantic.net>, hackers@FreeBSD.ORG Subject: Re: making CVS more convenient Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean Chittenden wrote: > It'd be cool to teach CVSup to ignore updating certain files that have > been marked locally as "dirty" or "in flux" until they've been > committed through to the master repo. Even better would be to have > CVSup ignore making changes to designated branches (RELENG_5_SEANC). This issue comes up at least once a year. I first suggested this nearly 10 years ago, right after CVSup was first introduced. Due to logistical problems, this actually won't work, as we discovered after the first such discussion, around that time. What has to happen is an ability to CVSup a remote project repository into a local vendor branch. Local modifications occur on the vendor branch, which can then be tagged and merged at will with the vendor branch head, to create a new local vendor branch. The closest that CVS/CVSup has come to this is the idea of a local vendor branch that implicitly does not generate conflicts on a reimport. > 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, and it assumes that the main repo will not get tagged in between. 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". A more minor problem is that it replaced the version conflict with a "$FreeBSD$" conflict that CVSup has to ignore. What it really comes down to is use of tools. Using the "magic" branch number, it's possible to do what you want, if you are willing to commit the code twice, and maintain two copies, a snapshot and an active CVSup, of the repository, and update the snapshot from the active, when and if your changes are rolled in. And for changes that are refused... you have to generate a patch set from the snapshot, and apply it to the new snapshot, each time you want to update. So you flip between 2/3/2/3/2/3/2 repository copies, to enable you to deal with patch application conflicts, when they arise. > Maybe the above changes could be rolled into the rewrite of CVSup in > C. That's probably best. It would make changing the code to CVSup onto a local vendor branch much more accessible, and doing that would make it much easier to deal with all these issues: just check in on the local HEAD, and don't worry about it. Submit patches via a "cvs diff" vs. the HEAD and the vendor branch. Patches generated this way will "magically" disappear as the vendor branch is updated by CVSup. A bonus would be that, if you were building a product based on FreeBSD and several other projects that supported CVSup, by doing this, you could integrate them all into the same local repository. -- Terry 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?3E75010D.EEA8B4D>