Date: Sun, 16 Mar 2003 16:37:43 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Nate Williams <nate@yogotech.com> Cc: Sean Chittenden <sean@chittenden.org>, Sergey Babkin <babkin@bellatlantic.net>, hackers@FreeBSD.ORG Subject: Re: making CVS more convenient Message-ID: <3E7518D7.DA16352@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> <15989.1782.166458.477601@emerger.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > 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). I see how you are viewing this: as a means of avoiding a full CVSup. I think the reason the cache was wanted was not to avoid the CVSup, but to allow operations *other than CVSup* to proceed more quickly? If so, this kind of reduces the reason for having a local cache: attempt locally, and then, if successful, attempt remotely. > > 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. :) Specifically, it's for "the FreeBSD developer", not "the developer who uses FreeBSD". 8-). > > 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. I think this is still an issue because of the date, and because of the committer name. Even if the committer name is the same (in your scenario where "the FreeBSD developer" is the issue, I'll concede it might be, except in the mentor case), the timestamp will still shoot you in the foot. > However, this is all a pipe-dream, although Sergey's work is making it > less pie-in-the-sky. Yes. As I said: 10 years and counting. 8-). > 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. Yes, P4 solves a *lot* of the problems, except the mirroring in the first place. ClearCase is nice, in its way, but you are right about CVSup being a much better tool for the job; that's why all the people who complain about it continue running it anyway... 8-). -- 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?3E7518D7.DA16352>