Date: Sun, 16 Mar 2003 17:10:54 -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: <3E75209E.EDD1A593@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> <15989.6799.899838.89854@emerger.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > 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'. Yes. This is the main gripe you are representing here, in a nutshell, I think: "I want to CVSup, get on an airplane to the U.S., and be able to work like I normally work, without having to worry about synchronization, because it will happen automatically next time I connect up to the net." "In theory, application and theory are the same, but in application, they are not". 8-). > > 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. I don't think it can. The commits you want to make are to the local (offline) repository copy, and you want them to be reflected back to the online repository, automatically. This really can't happin, unless the order is "local, remote". You suggested that the order should be "remote, local", which solves a different problem: "I want to CVSup and get a local repository copy, make changes to the main repository, and have them reflected in my local copy without a time-consuming CVSup. In other words, I want my local repository treated as a cache with an explicit coherency protocol to save me invalidations on write-through instead of write-back." Making this work is substantially harder, but at least by doing the commit to the remote repository first, and stalling the local commit until after it succeeds, means that you have the remote repository information "in hand" when you go to do the local commit, so you can either "invalidate" the local copy if it's older than the repository copy (one file CVSup), or, as happens now, refuse the commit. Maybe the way to handle this *could* be a cache, but it would be a weird animal: you would need to batch pending commits to the remote repository locally, but checkouts from the local repository would be pending until later. This risks an intermediate commit on a file being "lost", or a loss of modification history for multiple commits on the same file, but it *could* be made to work, though there would be a real PITA with regard to CVSROOT moving around, unless you used some way to suppress path... The way you would do this is... snapshots! ...TA DA! Snapshot the local CVS repository copy, and then make commits locally. By examining the deltas between the local repository and the snapshot of it, you could "replay" commits into the remote repository. The problem here is that in the case of a conflict, you would need to discard the new image in favor of the snapshot; you might also run into conflicts, but if the "replay" mechanism were able to deal with it, it could "rewrite history", so that you don't lose modification history, and you don't lose any incremental state (e.g. I add a manifest constant and use it in another file, and then I change the name, and I get a checkin conflict between the two). But as you said before, this is probably wishful thinking: for it to work, you would need to fiddle the dates, which would open some huge holes, I think. > > > 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 Yep, I expected so; I think everyone does... hence the "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. > > ???? If the files are the same version, the committer name would also > be the same in the Id tag, even when it's committed. Nope. I commit locally as "nwilliams", and then I commit on FreeBSD.org as "nate". Then I try to update, and the versions match, but the tag data in the file itself doesn't. > > 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. Ah, OK, then I retract the timestamp argument. -- 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?3E75209E.EDD1A593>