Date: Sun, 16 Mar 2003 17:45:03 -0700 From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Nate Williams <nate@yogotech.com>, Sean Chittenden <sean@chittenden.org>, Sergey Babkin <babkin@bellatlantic.net>, hackers@FreeBSD.ORG Subject: Re: making CVS more convenient Message-ID: <15989.6799.899838.89854@emerger.yogotech.com> In-Reply-To: <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> <3E7518D7.DA16352@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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? Having a local 'CVS' tree mirrored already does this. However, it's a hassle since everytime you make a commit, you have to modify the parameters (or use an alias), and after the commit has completed, you have to resynchronize your mirrored tree otherwise your commit will be lost on your first 'cvs update'. > If so, this kind of reduces the reason for having a local cache: > attempt locally, and then, if successful, attempt remotely. See above. It reduces the 'hassle' factor immensely. > > > > 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-). I wasn't trying to imply that the CVS mods were specifically targeted at FreeBSD users. For what it's worth, I have *numerous* occasions outside of the project where this functionality would have been helpful > > > 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. ???? If the files are the same version, the committer name would also be the same in the Id tag, even when it's committed. > 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. CVS doesn't use timestamps. The Id is also created at checkout time, so it's value in the database is mostly irrelevant. > > 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-). *grin* 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.6799.899838.89854>