> > > 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-).
Sort of. I want to be able to CVSup, get on an airplane, create a bunch of changes (all the while having access to logs, ability to do diffs, etc..), get off an airplane, dialup from my hotel, commit my changes, and have everything *just* work w/out having to re-synchronize my tree. Right now, I can do this, but it requires a lot of steps to get right, and there's room for mistakes being made the entire time. (Accidentally committing changes to the local tree which get lost upon re-synchronization, confusion on the part of the users, requiring additional tools such as CVSup, configuration, etc..) > > > 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. See above. I'm not expecting to commit when offline. I'm expecting to commit online, but I don't want to have to setup the CVSupd at the remote end, ensure that anytime we add new modules it's kept up-to-date, ensure that the users don't accidentally commit to the wrong tree, etc.. I want to set things up *once* in CVS, and have it *just* work. If they attempt to commit but don't have a connection to the master, then CVS will fail to allow the commit. If they attempt to commit and their local version does not match the version in the master, it fails. You get the picture. What you described (and I deleted) was a description of what might be nice, but what I think is nearly impossible to do correctly 100% of the time. > > > > > 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. I couldn't commit as 'nwilliams' on the master repository, since the master doesn't allow commits by nwilliams. Again, when commits are done, they are done *remotely* against the master, and then 'mirrored' in the local cache. However, if they master aborts the commit, it simply won't get done locally. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
