Re: making CVS more convenient
Terry Lambert wrote: > > Sergey Babkin wrote: > > Terry Lambert wrote: > > > > # OK, let's suppose that our changes are finally complete, and nobody > > > > # else has committed any other changes in between > > > > cvs ci > > > > > > Suppose someone has? If you are so out of touch with the net you > > > need a cache, you are probably going to get a conflict, because > > > > It's very likely that the conflict can be cured by a simple > > "cvs update". > > How? Your local repository is out of date. You can't update > your local repository because it's a cache, and the cache contains > some local changes, and any update will bow those changes away, or > abort because there's a conflict. This is exactly my "incoherent" > picture. No, it does not contain the local changes. The local changes are in a completely separate repository. (Well, if the same repository could be made to contain the local changes without upsetting cvsup and cvs, that would be just as good or better. But that seems to be too difficult, a completely separate repository for local changes looks easier). Hope that clarifies the picture. > You can't make local checkins to the same place CVSup writes to; > CVS is too stupid, and CVSup is too stupid to handle it. You'd > need a "multicvs" -- one that could operate a shadow repository. Yes. I guess we just had terminological difficulties with explaining this point to each other :-) -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Sergey Babkin wrote: > Terry Lambert wrote: > > > # OK, let's suppose that our changes are finally complete, and nobody > > > # else has committed any other changes in between > > > cvs ci > > > > Suppose someone has? If you are so out of touch with the net you > > need a cache, you are probably going to get a conflict, because > > It's very likely that the conflict can be cured by a simple > "cvs update". How? Your local repository is out of date. You can't update your local repository because it's a cache, and the cache contains some local changes, and any update will bow those changes away, or abort because there's a conflict. This is exactly my "incoherent" picture. Are you saying that you can "cvs update" vs. the main repository the checked out local sources, merge the changes, and do it that way? If you do that, you lose your locally maintained modification history. > > > So pretty much all I want is to make this procedure a bit more > > > convenient, able to handle whole subdirectories as opposed > > > to separate files. > > > > That's reasonable, but... you're rcs ci is a killer; it assumes > > a local repostory in parallel. I guess you want a "multicvs", > > which does checkins remotely or locally? > > I'm not sure what is a "multicvs", I just want to have some > storage for the data before I get to commit it to the real > repository. For example, suppose I write some code. Then I run > a test on it and find some deficency that needs a non-obvious > fix. At this point I want to save the present version somewhere > before I start doing the fix, to make sure that I at least > won't make things worse, and if I make them worse then I can > always return back. After the fix is done and the test > runs successfully, the final result can be committed to the > central repository. You want to save it in a local cache. I get that. The local cache is "a snapshot of the remote repository, which is out of date", right? You don't have access to the remote repository in order to make the local cache "not out of date". So you commit it to the local cache. You find you need a fix, make another change, and then commit *that* to the local cache. Then you want to commit the changes in the local cache to the remote repository. Have I understood you so far? If so: Q1: The original commit comment is some long-winded thing that explains the reason for the change, and the next comment is a terse "fix logic error in hash lookup", and the next comment is a long-winded thing about another new feature. Do you want to maintain the modification history for the intermediate local copies? Q2: If the answer to Q1 is "no", then what the heck happens to the commit comments for the first several commits? Q3: If the answer to Q2 is "glue them all together", then do you maintain a commit per comment, to keep comments like "fix logic error in hash lookup" meaningful, or do you just dump meaningless comments into the main repository later? > > ,---.-cvsup(1)->,---. > > | Main | cvsup(2)->| Cache |<--. > > | Repo |[CONFLICT] | Repo | | > > `---' `---' | > > ^ | | > > |cvs co | > > cvs ci(2) | cvs ci(1) > > [CONFLICT] V | > > cvs ci(3) ,---. | > > | | Work | | > > `---| Copy |---' > > `---' [ ... ] > When cvs ci(2) finds a conflict, the master repository is left > unchanged. So cvsup will never see any conflicts. The real sequence > would be > > cvsup(1) > cvs co > cvs ci(1) > cvs ci(2) [CONFLICT - check-in fails] > cvsup(2) BOOM! YOUR HEAD EXPLODES! cvsup(2) will consider the cache repository HEAD trashed. It will either abort, or it will overwrite your cache contents, and you will lose your local modifications. Either way, you are screwed. You can't make local checkins to the same place CVSup writes to. > > The first time you get a conflict, your MYCVSROOT repository > > is blown, and you won't be able to resyncronize it, without > > replacing ",v" and "CVS/*" file contents. > > No. Two repositories in this example are completely independent. > Their only connection is by checking in and out the same file > manually. That's not there in this diagram. I tried to give you a second diagram, which I labelled "coherent", which had a second, seperate local repository, but you guys rejected it. You can't make local checkins to the same place CVSup writes to; CVS is too stupid, and CVSup is too stupid to handle it. You'd need a "multicvs" -- one that could operate a shadow repository. I still
Re: making CVS more convenient
Terry Lambert wrote: > > Sergey Babkin wrote: > > # OK, let's suppose that our changes are finally complete, and nobody > > # else has committed any other changes in between > > cvs ci > > Suppose someone has? If you are so out of touch with the net you > need a cache, you are probably going to get a conflict, because It's very likely that the conflict can be cured by a simple "cvs update". > > So pretty much all I want is to make this procedure a bit more > > convenient, able to handle whole subdirectories as opposed > > to separate files. > > That's reasonable, but... you're rcs ci is a killer; it assumes > a local repostory in parallel. I guess you want a "multicvs", > which does checkins remotely or locally? I'm not sure what is a "multicvs", I just want to have some storage for the data before I get to commit it to the real repository. For example, suppose I write some code. Then I run a test on it and find some deficency that needs a non-obvious fix. At this point I want to save the present version somewhere before I start doing the fix, to make sure that I at least won't make things worse, and if I make them worse then I can always return back. After the fix is done and the test runs successfully, the final result can be committed to the central repository. > > As a model consider this: suppose we build a separate copy of the CVS > > binary, called "mycvs" that has the following differences from > > the normal CVS: > > That's actually grosser than the rcs version (IMO)... It's only an example to show an analogy. Though after thinking about it, it looks like a good model to start with and cover under the hood of cvs commands. > > > of verbatim copying of the repository. > > > > > > Incoherent: > > [ ... diagram ... ] > > > Why is it incoherent ? CVS checks that the version obtained by "cvs co" > > and then modified is still the top of the tree. If it's not, > > it will refuse to commit and will request you to do an update. > > I left out the (I thought) obvious part; ket me fix it: > > ,---.-cvsup(1)->,---. > | Main | cvsup(2)->| Cache |<--. > | Repo |[CONFLICT] | Repo | | > `---' `---' | > ^ | | > |cvs co | > cvs ci(2) | cvs ci(1) > [CONFLICT] V | > cvs ci(3) ,---. | > | | Work | | > `---| Copy |---' > `---' > > Order: > cvsup(1) > cvs co > cvs ci(1) > cvs ci(2) [CONFLICT] > [FIX] cvs ci(3) > cvsup(2) [CONFLICT] > > In other words, you can't order commits with conflicts, without > going to the main repo first in call cases. That destroys your > intended disconnected use. When cvs ci(2) finds a conflict, the master repository is left unchanged. So cvsup will never see any conflicts. The real sequence would be cvsup(1) cvs co cvs ci(1) cvs ci(2) [CONFLICT - check-in fails] cvsup(2) cvs update [hopefully update resolves the conflict, or fix it manually] cvs ci(3) > The first time you get a conflict, your MYCVSROOT repository > is blown, and you won't be able to resyncronize it, without > replacing ",v" and "CVS/*" file contents. No. Two repositories in this example are completely independent. Their only connection is by checking in and out the same file manually. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Sergey Babkin wrote: > Terry Lambert wrote: > > Not really possible, without CVSup coming onto a vendor branch instead > > Actually, I was thinking of the opposite: doing all the changes > on a vendor branch (or in some separate local repository altogether), > then merging them into the main branch. Think of the following > sequence that can be used now: [ ... ] > # OK, let's suppose that our changes are finally complete, and nobody > # else has committed any other changes in between > cvs ci Suppose someone has? If you are so out of touch with the net you need a cache, you are probably going to get a conflict, because people are tweaking things all the time, sometimes, it seems, rearranging the deck chairs to get their name in CVS lights. 8-). > So pretty much all I want is to make this procedure a bit more > convenient, able to handle whole subdirectories as opposed > to separate files. That's reasonable, but... you're rcs ci is a killer; it assumes a local repostory in parallel. I guess you want a "multicvs", which does checkins remotely or locally? If you want all of your checkins checked in, then you could do this with a shell script wrapper that knew about "link up" on your network interfaces. Is that a possible solution for you? > As a model consider this: suppose we build a separate copy of the CVS > binary, called "mycvs" that has the following differences from > the normal CVS: > > 1. Instead of the variable CVSROOT it uses MYCVSROOT > 2. Instead of the metadata subdirectory name CVS it uses the name MYCVS > 3. It never touches any of the keywords (such as $Id etc.) > 4. When asked to add a file, it automatically creates the whole > path of intermediate directories for it. (How does it know where > the checked-out tree starts ? There are many more or less > obvious and convenient ways to do that, so let's leave this issue > alone for now). > > Then in the example above you can do > > export MYCVSROOT=~/tmp/cvsroot > mycvs init > > And do everyhing as in the previous example, only replacing rcs > with mycvs (and obviously you wold need to do "mycvs add" before > the fiest "mycvs ci"). That's actually grosser than the rcs version (IMO)... > > of verbatim copying of the repository. > > > > Incoherent: [ ... diagram ... ] > Why is it incoherent ? CVS checks that the version obtained by "cvs co" > and then modified is still the top of the tree. If it's not, > it will refuse to commit and will request you to do an update. I left out the (I thought) obvious part; ket me fix it: ,---.-cvsup(1)->,---. | Main | cvsup(2)->| Cache |<--. | Repo |[CONFLICT] | Repo | | `---' `---' | ^ | | |cvs co | cvs ci(2) | cvs ci(1) [CONFLICT] V | cvs ci(3) ,---. | | | Work | | `---| Copy |---' `---' Order: cvsup(1) cvs co cvs ci(1) cvs ci(2) [CONFLICT] [FIX] cvs ci(3) cvsup(2) [CONFLICT] In other words, you can't order commits with conflicts, without going to the main repo first in call cases. That destroys your intended disconnected use. The first time you get a conflict, your MYCVSROOT repository is blown, and you won't be able to resyncronize it, without replacing ",v" and "CVS/*" file contents. In other words, any time, there is a "checkin to main repository" conflict, your foot goes "bye bye"... Make sense? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
> > > It gets handled in the same way as now: I believe, CVS checks > > > whether the checked-out version matches the top of the branch, > > > and if it does not then it refuses to commit and requires you > > > to make an update. So the same thing can be done for a "local branch": > > > check that its base version is still the top of the real branch, > > > and if so then commit. Otherwise require an update/merge. > > > > Except that it's possible that the 'local' cache is out-of-date > > w/respect to the remote repository, say if someone made a commit to it > > since the last 'synchronization' of the local cache. > > > > You don't want that commit to happen, since it should be allowed because > > the file is really not up-to-date w/respect to the master. The worst > > case is the committed change would conflict with the as-yet-unseen > > change on the master, so allowing the local user to commit it means that > > when the 'cache' attempts to commit it later, it will fail, and the > > 'cache code' is required to figure out how to extract the commit from > > the local cache, update the local cache, re-apply the (now conflicing) > > commit back to the local cache and somehow inform the user at a later > > point. > > > > *UGH* > > Yes, this is way too complicated and error-prone. This is why I don't > want to change the cache without changing the master in the same way > first. I think we're in *violent* agreement at this point. :) > > > > If you only allow the commit if it can occur locally, you're ensuring > > > > that the cache can't get out of date with local changes. I tried > > > > something like the above (cause it was easier to implement), and it > > > > worked most of the time. However, the times it didn't work it was a > > > > royal pain in the *ss to cleanup and get the original commit back out. > > > > > > Maybe I just was not clear: I think that making the commits in the > > > local copy on the real top of the tree is a quite bad idea. > > > > I think it's a good idea *IF and only IF* the commit to the remote tree > > works. That way, the local user isn't required to re-synchronize his > > cached tree agains the master tree, since their is a high liklihood that > > Agreed. So the commit would essentially work as a commit plus > resynchronization of a subset of files in the cache. *grin* I love it when a plan comes together. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Nate Williams wrote: > > > It gets handled in the same way as now: I believe, CVS checks > > whether the checked-out version matches the top of the branch, > > and if it does not then it refuses to commit and requires you > > to make an update. So the same thing can be done for a "local branch": > > check that its base version is still the top of the real branch, > > and if so then commit. Otherwise require an update/merge. > > Except that it's possible that the 'local' cache is out-of-date > w/respect to the remote repository, say if someone made a commit to it > since the last 'synchronization' of the local cache. > > You don't want that commit to happen, since it should be allowed because > the file is really not up-to-date w/respect to the master. The worst > case is the committed change would conflict with the as-yet-unseen > change on the master, so allowing the local user to commit it means that > when the 'cache' attempts to commit it later, it will fail, and the > 'cache code' is required to figure out how to extract the commit from > the local cache, update the local cache, re-apply the (now conflicing) > commit back to the local cache and somehow inform the user at a later > point. > > *UGH* Yes, this is way too complicated and error-prone. This is why I don't want to change the cache without changing the master in the same way first. > > > If you only allow the commit if it can occur locally, you're ensuring > > > that the cache can't get out of date with local changes. I tried > > > something like the above (cause it was easier to implement), and it > > > worked most of the time. However, the times it didn't work it was a > > > royal pain in the *ss to cleanup and get the original commit back out. > > > > Maybe I just was not clear: I think that making the commits in the > > local copy on the real top of the tree is a quite bad idea. > > I think it's a good idea *IF and only IF* the commit to the remote tree > works. That way, the local user isn't required to re-synchronize his > cached tree agains the master tree, since their is a high liklihood that Agreed. So the commit would essentially work as a commit plus resynchronization of a subset of files in the cache. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Terry Lambert wrote: > > Sergey Babkin wrote: > > Nate Williams wrote: > > [ ... "CVS cache and cache coherency" ... ] > > > Yet another idea is to be able to make "local commits" with committing > > them to the central remote repository later. Now I have to use RCS > > locally for the temporary in-delevopment versions of file. Would > > be nice to have a kind of a local branch which can be later committed > > as a whole - in one commit per file, or by duplicating all the > > intermediate versions with their messages. > > Not really possible, without CVSup coming onto a vendor branch instead Actually, I was thinking of the opposite: doing all the changes on a vendor branch (or in some separate local repository altogether), then merging them into the main branch. Think of the following sequence that can be used now: cvs co rcs ci # save the baseline #... some modifications done rcs ci #... more modifications rcs ci # then someone committed another change to the repository and we want # to merge that change in cvs update # do the manual merge if neccessary rcs ci # save the merged version #... more modifications rcs ci # OK, let's suppose that our changes are finally complete, and nobody # else has committed any other changes in between cvs ci So pretty much all I want is to make this procedure a bit more convenient, able to handle whole subdirectories as opposed to separate files. As a model consider this: suppose we build a separate copy of the CVS binary, called "mycvs" that has the following differences from the normal CVS: 1. Instead of the variable CVSROOT it uses MYCVSROOT 2. Instead of the metadata subdirectory name CVS it uses the name MYCVS 3. It never touches any of the keywords (such as $Id etc.) 4. When asked to add a file, it automatically creates the whole path of intermediate directories for it. (How does it know where the checked-out tree starts ? There are many more or less obvious and convenient ways to do that, so let's leave this issue alone for now). Then in the example above you can do export MYCVSROOT=~/tmp/cvsroot mycvs init And do everyhing as in the previous example, only replacing rcs with mycvs (and obviously you wold need to do "mycvs add" before the fiest "mycvs ci"). > of verbatim copying of the repository. > > Incoherent: > > ,---. ,---. > | Main | cvsup --->| Cache | > | Repo | | Repo | > `---' `---' > ^ | > |cvs co > cvs ci | > | V > | ,---. > | | Work | > `---| Copy | > `---' Why is it incoherent ? CVS checks that the version obtained by "cvs co" and then modified is still the top of the tree. If it's not, it will refuse to commit and will request you to do an update. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Dag-Erling SmЬrgrav wrote: > > Sergey Babkin <[EMAIL PROTECTED]> writes: > > A similar thing may be achieved by checking the files out from the local > > repository and doing any modification command with option -d. But that's > > troublesome and inconvenient. > > Read the manual page for the shell you're using, with particular > emphasis on the 'alias' builtin command. I think that it's not a good solution, for several reasons: * Using -d for an alternative repository is pretty much a dirty trick, and undocumented one too. But the purpose itself is quite valid, transparent, and simple and I think that it's better to make it obvious and easy to use than tricky. I like the principle "simple things should be easy, complex things should be possible". * There may be scripts that run cvs commands, which scripts absolutely don't need to know about a cache repository underneath. * I don't like the layers of "workaround scripts" built over other "workaround scripts". I think that it's something of an "aftermarket Unix syndrome": when you can trick a tool to do what you want and wrap it into a script for the ease of use but can't change the tool to do what you need directly, in a simple way. The original Unix (both Bell Labs and BSD) was not like this: when the people made some useful addition, they just got it right into the base system. Now with open source OSes we can do the same thing and not look for extra pain with wrapper scripts. * Getting the cache repository support right into CVS allows to modify the CVS commands in future to take advantage of this knowledge. For example, "commit" may not just check the modification date and send the file to the server if it has changed, but instead also compare the file with the one in the cache repository and send it to the server only if the file has actually changed. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
> > > That's the plan for the next stage, provided that the first stage > > > goes well. I'm yet to play with CVSup and see if it can be > > > integrated there (as with system()) easily without making a lot > > > of changes to CVS itself. Otherwise I'm aftarid it's going to > > > be a large amount of work to duplicate this functionality :-( > > > > Another choice is to have the commit be also made to the 'cache' if and > > only if the remote (master) respository has accepted the commit. > > > > That way, the commit is made in both repositories using the same > > algorithm, so in essence they should be in sync. > > Yes, makes sense. > > > > Yet another idea is to be able to make "local commits" with committing > > > them to the central remote repository later. > > > > I'd do the reverse, since the possibility of synchronization problems > > are a huge deal. Imagine if someone 'snuck' in and made a commit in > > the master tree after your local commit was made, but before 'later' > > occurred and your cache pushed it out to the master tree. > > It gets handled in the same way as now: I believe, CVS checks > whether the checked-out version matches the top of the branch, > and if it does not then it refuses to commit and requires you > to make an update. So the same thing can be done for a "local branch": > check that its base version is still the top of the real branch, > and if so then commit. Otherwise require an update/merge. Except that it's possible that the 'local' cache is out-of-date w/respect to the remote repository, say if someone made a commit to it since the last 'synchronization' of the local cache. You don't want that commit to happen, since it should be allowed because the file is really not up-to-date w/respect to the master. The worst case is the committed change would conflict with the as-yet-unseen change on the master, so allowing the local user to commit it means that when the 'cache' attempts to commit it later, it will fail, and the 'cache code' is required to figure out how to extract the commit from the local cache, update the local cache, re-apply the (now conflicing) commit back to the local cache and somehow inform the user at a later point. *UGH* > > If you only allow the commit if it can occur locally, you're ensuring > > that the cache can't get out of date with local changes. I tried > > something like the above (cause it was easier to implement), and it > > worked most of the time. However, the times it didn't work it was a > > royal pain in the *ss to cleanup and get the original commit back out. > > Maybe I just was not clear: I think that making the commits in the > local copy on the real top of the tree is a quite bad idea. I think it's a good idea *IF and only IF* the commit to the remote tree works. That way, the local user isn't required to re-synchronize his cached tree agains the master tree, since their is a high liklihood that after the commit the user will also want to continue working on the same files. If no re-sychronization occurs, as soon as an 'cvs update' is done, the local cache must either re-synchronize itself (doing the exact same work as if it just done the commit), or the newly committed change will be reverted back out, since the local cache will now be out-of-date. > I want to get is some temporary versioned storage to play around > while I work on the code. After the code gets finished, it > gets committed to the master repository just as it committed gets now. What happens to the local cache *right after* the commit occurs? In essence, it's no longer valid right after a commit, since it's now out-of-date with the master (it doesn't include the newly committed changes). > > > Now I have to use RCS > > > locally for the temporary in-delevopment versions of file. Would > > > be nice to have a kind of a local branch which can be later committed > > > as a whole - in one commit per file, or by duplicating all the > > > intermediate versions with their messages. > > > > Agreed. The downside to the above method is that it requires network > > access to make a commit. However, it certainly simplifies the > > problem set. :) :) > > Well, at least the commit would get done in one batch (of course, > unless a conflict happens). Right, it's a step in the right direction. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Nate Williams wrote: > > > That's the plan for the next stage, provided that the first stage > > goes well. I'm yet to play with CVSup and see if it can be > > integrated there (as with system()) easily without making a lot > > of changes to CVS itself. Otherwise I'm aftarid it's going to > > be a large amount of work to duplicate this functionality :-( > > Another choice is to have the commit be also made to the 'cache' if and > only if the remote (master) respository has accepted the commit. > > That way, the commit is made in both repositories using the same > algorithm, so in essence they should be in sync. Yes, makes sense. > > Yet another idea is to be able to make "local commits" with committing > > them to the central remote repository later. > > I'd do the reverse, since the possibility of synchronization problems > are a huge deal. Imagine if someone 'snuck' in and made a commit in > the master tree after your local commit was made, but before 'later' > occurred and your cache pushed it out to the master tree. It gets handled in the same way as now: I believe, CVS checks whether the checked-out version matches the top of the branch, and if it does not then it refuses to commit and requires you to make an update. So the same thing can be done for a "local branch": check that its base version is still the top of the real branch, and if so then commit. Otherwise require an update/merge. > If you only allow the commit if it can occur locally, you're ensuring > that the cache can't get out of date with local changes. I tried > something like the above (cause it was easier to implement), and it > worked most of the time. However, the times it didn't work it was a > royal pain in the *ss to cleanup and get the original commit back out. Maybe I just was not clear: I think that making the commits in the local copy on the real top of the tree is a quite bad idea. All I want to get is some temporary versioned storage to play around while I work on the code. After the code gets finished, it gets committed to the master repository just as it committed gets now. > > Now I have to use RCS > > locally for the temporary in-delevopment versions of file. Would > > be nice to have a kind of a local branch which can be later committed > > as a whole - in one commit per file, or by duplicating all the > > intermediate versions with their messages. > > Agreed. The downside to the above method is that it requires network > access to make a commit. However, it certainly simplifies the > problem set. :) :) Well, at least the commit would get done in one batch (of course, unless a conflict happens). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
David Schultz wrote: > Thus spake Terry Lambert <[EMAIL PROTECTED]>: > > 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. > > So Terry has actually been writing code for the FreeBSD project > all these years and nobody knew it! And here I thought Nate was > doing all of his own work. Ar ar. PS: Can you vouch for personally having met everyone with a commit bit? No telling _who_ has commit access to the tree... gotta wonder... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Thus spake Terry Lambert <[EMAIL PROTECTED]>: > 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. So Terry has actually been writing code for the FreeBSD project all these years and nobody knew it! And here I thought Nate was doing all of his own work. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
> > > 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
Re: making CVS more convenient
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 m
Re: making CVS more convenient
> > > 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
On Sun, Mar 16, 2003 at 04:32:48PM -0700, Nate Williams wrote: > > What is the status of Perforce in the FreeBSD project? Is the issue the > > absence of a "p4up"? Licensing? Inertia? > > See the archives for a more thorough discussion, but I believe the > licensing is the biggest issue. If we moved to use commercial software, > it would make our development much more difficult for the average > developer to track our progress. I think one only needs to take a look at the Linux community and the situation they have found themselves in wrt to BitKeeper to understand the risks associated with making a project dependent on commercial source control. Even if our license with Perforce were rather liberal, without access to the Perforce source code we are leaving a lot of things to chance. What happens if Perforce folds or discontinues their source control product? Are our bits forever trapped inside a p4 repo which is dependent on binaries which may eventually cease working with our ABI and/or APIs and require a compatibility layer? What if we port to new platforms which Perforce doesn't offer binaries for (or even worse, they've folded and we can no longer get new binaries)? I think we have an opportunity to learn from the mistakes Linux has made here and we'd be foolish not to. It is important to note that CVS and Perforce are nowhere near the only options available in this space. In fact, CVS is not the only open source product out there. I think FreeBSD would be wise to consider a move to Subversion[0] when it reaches release, as it fixes most of the bugs and complaints about CVS while following POLA. svn(1) works pretty much like cvs(1) and that's a Good Thing. For a full discussion of the various SCMs available, both open source and proprietary, see Rick Moen's listing of them[1]. [0] - http://subversion.tigris.org/ [1] - http://linuxmafia.com/~rick/linux-info/scm.html Brandon D. Valentine -- [EMAIL PROTECTED] http://www.geekpunk.net Pseudo-Random Googlism: valentine is currently undertaking an esrc funded research project into living on the edge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Sean Chittenden <[EMAIL PROTECTED]> writes: > Right, which is what I was trying to suggest a fix for in the first > place: the ability to prevent the loss of work committed to a local > repository when using cvsup to sync repositories with the master repo. if you *want* to keep the local changes (I thought you didn't because they'd be reflected in the master repo) there is a documented mechanism for committing local changes on a CVS branch which cvsup will ignore. RTFM. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: making CVS more convenient
Nate Williams wrote: > > The current version of Perforce has "p4proxy" which caches > a local copy > > of the depot files used. > > Does it still require a working net link to the master > repository? When > it was originally released, I remember it being useful for slow links, > but not so good on non-existant links (ie; airplane rides, etc..) Yes, it still requires a working link. Perforce depends on being able to keep its database of client state up to date. > > What is the status of Perforce in the FreeBSD project? > > See the archives for a more thorough discussion, but I believe the > licensing is the biggest issue. If we moved to use > commercial software, > it would make our development much more difficult for the average > developer to track our progress. I'll take a look. Presumably something like a "p4up" could get around that. Regards, Jan. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: making CVS more convenient
> > 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. > > The current version of Perforce has "p4proxy" which caches a local copy > of the depot files used. Does it still require a working net link to the master repository? When it was originally released, I remember it being useful for slow links, but not so good on non-existant links (ie; airplane rides, etc..) > What is the status of Perforce in the FreeBSD project? Is the issue the > absence of a "p4up"? Licensing? Inertia? See the archives for a more thorough discussion, but I believe the licensing is the biggest issue. If we moved to use commercial software, it would make our development much more difficult for the average developer to track our progress. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: making CVS more convenient
Nate Williams wrote: > 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. The current version of Perforce has "p4proxy" which caches a local copy of the depot files used. To the p4 client, it looks just like the server. The Perforce model makes this a bit easier with a significant amount of client state stored on the server. What is the status of Perforce in the FreeBSD project? Is the issue the absence of a "p4up"? Licensing? Inertia? Regards, Jan Mikkelsen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
> > 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 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). > 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. :) > 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". Even during code-freeze, it does allow you to everything you *need* to do safely. If you attempt a commit and your local cache isn't up-to-date, then the commit will fail, and the user will have to re-sychronize their repository. Fortunately, this is a mostly rare occurance, especially if there are regular scheduled synchronization occurances (aka; nightly cron jobs). > 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. However, this is all a pipe-dream, although Sergey's work is making it less pie-in-the-sky. 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. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Sergey Babkin wrote: > Nate Williams wrote: [ ... "CVS cache and cache coherency" ... ] > Yet another idea is to be able to make "local commits" with committing > them to the central remote repository later. Now I have to use RCS > locally for the temporary in-delevopment versions of file. Would > be nice to have a kind of a local branch which can be later committed > as a whole - in one commit per file, or by duplicating all the > intermediate versions with their messages. Not really possible, without CVSup coming onto a vendor branch instead of verbatim copying of the repository. Incoherent: ,---. ,---. | Main | cvsup --->| Cache | | Repo | | Repo | `---' `---' ^ | |cvs co cvs ci | | V | ,---. | | Work | `---| Copy | `---' Coherent: ,---. ,---. | Main | cvsup --->| Cache | | Repo | | Repo | `---' / `---' ^ / (Vendor Branch) |(HEAD) / | ,---. cvs ci --->| Cache | ^ | Repo | | `---' | | |cvs co | | | V | ,---. | | Work | `---| Copy | `---' This also happens to solve the "I do all my developement work for my company using -STABLE" problem... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
> > [local commit to file A ] > > [different developer commits to file A on master repo] > > [commit to file A on master repo] > > [cvsup local repo with master repo] > > > > Wouldn't you have to delete A,v before A,v would continue to pick up > > future changes? -sc > > No, cvsup would notice that the local file has the wrong size and > re-fetch it (rather than just add the missing delta) so the local > change would be replaced with the remote change. Right, which is what I was trying to suggest a fix for in the first place: the ability to prevent the loss of work committed to a local repository when using cvsup to sync repositories with the master repo. -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Sean Chittenden <[EMAIL PROTECTED]> writes: > [local commit to file A ] > [different developer commits to file A on master repo] > [commit to file A on master repo] > [cvsup local repo with master repo] > > Wouldn't you have to delete A,v before A,v would continue to pick up > future changes? -sc No, cvsup would notice that the local file has the wrong size and re-fetch it (rather than just add the missing delta) so the local change would be replaced with the remote change. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
> > > With the -s option, cvsup will not touch files that it believes are > > > in sync until they are updated on the server. > >^^^ > >not ? > > no, not "not". "cvsup will not touch files that it believes are in > sync", the operative word here being "believes" - with -s cvsup will > use the checkout list and won't even look at the actual file unless > the server says it has a newer version than what is listed in the > checkout list. I think we're having a mis-communication. I want cvsup to edit the files that are in sync with the master server. I want cvsup to ignore or leave alone files that are out of sync with the server (ie: don't re-transfer the file in the assumption that its been "corrupted"). We working from the same set of intentions and just colliding in the communication dept (most likely what it means to be in "sync")? > > -s is a bit dicey to trust unless you grab an exclusive lock on > > the file and prevent other people from making a change to the file > > on the server. -sc > > You actually *want* the -s induced failure in this case. If -s induces a failure when there are local changes that haven't come down from the master repo, that'd be slick... it still sounds like you'd have to clear your ,v file if you commit your changes after someone had made a change to the file after you made a local commit. [local commit to file A ] [different developer commits to file A on master repo] [commit to file A on master repo] [cvsup local repo with master repo] Wouldn't you have to delete A,v before A,v would continue to pick up future changes? -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Sean Chittenden <[EMAIL PROTECTED]> writes: > > With the -s option, cvsup will not touch files that it believes are > > in sync until they are updated on the server. >^^^ >not ? no, not "not". "cvsup will not touch files that it believes are in sync", the operative word here being "believes" - with -s cvsup will use the checkout list and won't even look at the actual file unless the server says it has a newer version than what is listed in the checkout list. > -s is a bit dicey to trust unless you grab an exclusive lock on the > file and prevent other people from making a change to the file on the > server. -sc You actually *want* the -s induced failure in this case. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
> > 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. > > With the -s option, cvsup will not touch files that it believes are > in sync until they are updated on the server. ^^^ not ? -s is a bit dicey to trust unless you grab an exclusive lock on the file and prevent other people from making a change to the file on the server. -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Sean Chittenden <[EMAIL PROTECTED]> writes: > 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. With the -s option, cvsup will not touch files that it believes are in sync until they are updated on the server. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Sergey Babkin <[EMAIL PROTECTED]> writes: > A similar thing may be achieved by checking the files out from the local > repository and doing any modification command with option -d. But that's > troublesome and inconvenient. Read the manual page for the shell you're using, with particular emphasis on the 'alias' builtin command. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
> > Yet another idea is to be able to make "local commits" with committing > > them to the central remote repository later. > > I'd do the reverse, since the possibility of synchronization problems > are a huge deal. Imagine if someone 'snuck' in and made a commit in > the master tree after your local commit was made, but before 'later' > occurred and your cache pushed it out to the master tree. > > If you only allow the commit if it can occur locally, you're ensuring > that the cache can't get out of date with local changes. I tried > something like the above (cause it was easier to implement), and it > worked most of the time. However, the times it didn't work it was a > royal pain in the *ss to cleanup and get the original commit back out. 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). 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. Maybe the above changes could be rolled into the rewrite of CVSup in C. CVSup -> C ld cvsup -lkse cvsup(1) -> base system ::grin:: -sc -- Sean Chittenden pgp0.pgp Description: PGP signature
Re: making CVS more convenient
> > > The value specified in CVSROOTCACHE is the local path to the cache > > > repository. All the check-outs, updates, diffs etc. will be obtained > > > from there. All the check-ins, tagging etc. will go into the master > > > repository specified by CVSROOT. Naturally, to see these changes > > > in the cache repository, it needs to be updated by some outside > > > means such as CVSup or CTM. > > > > So, the cache doesn't automagically update itself when commits are done? > > This is less useful, since often-times after a commit has been done the > > user is still working in the same general area, so a 'cvs update' would > > now give the user older files since the read-only cache is not > > up-to-date, thus making it a requirement that everytime you make a > > commit, you also sychronize the cache. > > That's the plan for the next stage, provided that the first stage > goes well. I'm yet to play with CVSup and see if it can be > integrated there (as with system()) easily without making a lot > of changes to CVS itself. Otherwise I'm aftarid it's going to > be a large amount of work to duplicate this functionality :-( Another choice is to have the commit be also made to the 'cache' if and only if the remote (master) respository has accepted the commit. That way, the commit is made in both repositories using the same algorithm, so in essence they should be in sync. This saves the overhead of running a complete synchronization of all the files. And, you have a safe 'fallback' of mirroring the remote tree which should cleanup any problems you had, which will still be for any non-local modifications. > Yet another idea is to be able to make "local commits" with committing > them to the central remote repository later. I'd do the reverse, since the possibility of synchronization problems are a huge deal. Imagine if someone 'snuck' in and made a commit in the master tree after your local commit was made, but before 'later' occurred and your cache pushed it out to the master tree. If you only allow the commit if it can occur locally, you're ensuring that the cache can't get out of date with local changes. I tried something like the above (cause it was easier to implement), and it worked most of the time. However, the times it didn't work it was a royal pain in the *ss to cleanup and get the original commit back out. > Now I have to use RCS > locally for the temporary in-delevopment versions of file. Would > be nice to have a kind of a local branch which can be later committed > as a whole - in one commit per file, or by duplicating all the > intermediate versions with their messages. Agreed. The downside to the above method is that it requires network access to make a commit. However, it certainly simplifies the problem set. :) :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
Nate Williams wrote: > > > The value specified in CVSROOTCACHE is the local path to the cache > > repository. All the check-outs, updates, diffs etc. will be obtained > > from there. All the check-ins, tagging etc. will go into the master > > repository specified by CVSROOT. Naturally, to see these changes > > in the cache repository, it needs to be updated by some outside > > means such as CVSup or CTM. > > So, the cache doesn't automagically update itself when commits are done? > This is less useful, since often-times after a commit has been done the > user is still working in the same general area, so a 'cvs update' would > now give the user older files since the read-only cache is not > up-to-date, thus making it a requirement that everytime you make a > commit, you also sychronize the cache. That's the plan for the next stage, provided that the first stage goes well. I'm yet to play with CVSup and see if it can be integrated there (as with system()) easily without making a lot of changes to CVS itself. Otherwise I'm aftarid it's going to be a large amount of work to duplicate this functionality :-( Yet another idea is to be able to make "local commits" with committing them to the central remote repository later. Now I have to use RCS locally for the temporary in-delevopment versions of file. Would be nice to have a kind of a local branch which can be later committed as a whole - in one commit per file, or by duplicating all the intermediate versions with their messages. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: making CVS more convenient
> The idea is to support a "cache" repository (the one copied to a local > machine by CVSup or CTM) transparently. So that the reads from > directory will go from the local cache repository (and won't > overstrain the remote server, and will be fast too), while the commits > and other changes will go into the remote master repository. Good stuff. I wanted something like this *years* ago when we first started using CVS in FreeBSD. > The value specified in CVSROOTCACHE is the local path to the cache > repository. All the check-outs, updates, diffs etc. will be obtained > from there. All the check-ins, tagging etc. will go into the master > repository specified by CVSROOT. Naturally, to see these changes > in the cache repository, it needs to be updated by some outside > means such as CVSup or CTM. So, the cache doesn't automagically update itself when commits are done? This is less useful, since often-times after a commit has been done the user is still working in the same general area, so a 'cvs update' would now give the user older files since the read-only cache is not up-to-date, thus making it a requirement that everytime you make a commit, you also sychronize the cache. If this could be done automagically, it would make the cache more 'coherent' and things much more useful. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
