Re: Ignore local changes?
[ On Wednesday, April 2, 2003 at 00:28:48 (-0600), Wade Williams wrote: ] Subject: Ignore local changes? I've got a file which I must make changes to on my system. However, I don't ever want my changes put back into the repository. Currently, I handle this by removing the file and re-updating the file from the repository before doing a commit. But is there a way I can tell CVS - always update this file on an update, but ignore my changes on a commit? Yes there is: Do not ever modify the CVS controlled file! Always, and only ever, modify a copy of any file if you don't want CVS to see your changes to it! I.e. this is a build system problem, not a CVS problem. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
Yes there is: Do not ever modify the CVS controlled file! Always, and only ever, modify a copy of any file if you don't want CVS to see your changes to it! I.e. this is a build system problem, not a CVS problem. No, it's not a CVS problem. However, CVS could make life easier with this as an option. I can't imagine I'm the only developer that makes local changes to try something out, but wants to be sure those changes do not end up in the repository. The problem with it's a build system problem is that the files in question are not a part of any build system. They're application configuration files. So, that requires me to modify the original file, and then make sure the original is back in place before committing so my changes are not put into the repository. But, it sounds as if I'd be beating my head against the wall by arguing this one further. Wade ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
[ On Wednesday, April 2, 2003 at 11:37:39 (-0600), Wade Williams wrote: ] Subject: Re: Ignore local changes? Yes there is: Do not ever modify the CVS controlled file! Always, and only ever, modify a copy of any file if you don't want CVS to see your changes to it! I.e. this is a build system problem, not a CVS problem. No, it's not a CVS problem. However, CVS could make life easier with this as an option. No, CVS cannot make this an option. Anything you suggest would, BY DEFINITION, subvert all the efforts CVS goes to to try to keep the integrity of its view of your working directory intact! If you want to modify a file and you don't want CVS to see those modifications then you _ABSOLUTELY_MUST_ make those modifications to a file which CVS does not manage -- e.g. a copy of the file with a new name that CVS does not see. If your build system can't easily be adjusted to deal with an alternative file like this then that's problem with your build system, not with CVS. Dealing with alternative files in normal compiled code development is usually very trivial: $ cp file.c local.c $ vi local.c $ cc -c local.c -o file.o $ make If you can't remember that you've made a special modified version of file.o then you shouldn't even be thinking of doing what you suggest -- you should just modify file.c directly and learn to more carefully inspect your changes before you commit them (and of course only commit those that you really want to commit)! I can't imagine I'm the only developer that makes local changes to try something out, but wants to be sure those changes do not end up in the repository. If that's the way you want to do things then you could make a copy of your working directory and remove the CVS administrative files and directories However if you want to use CVS to keep track of your changes then you don't want any easy way to subvert it! Put a comment in the changed file to remind you not to commit that change! This is _NOT_ a problem CVS can ever possibly address in any sane and safe way. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
Wade Williams wrote: Yes there is: Do not ever modify the CVS controlled file! Always, and only ever, modify a copy of any file if you don't want CVS to see your changes to it! I.e. this is a build system problem, not a CVS problem. No, it's not a CVS problem. However, CVS could make life easier with this as an option. I can't imagine I'm the only developer that makes local changes to try something out, but wants to be sure those changes do not end up in the repository. The problem with it's a build system problem is that the files in question are not a part of any build system. They're application configuration files. So, that requires me to modify the original file, and then make sure the original is back in place before committing so my changes are not put into the repository. But, it sounds as if I'd be beating my head against the wall by arguing this one further. Wade Actually, it may be a build system problem. If as a part of normal development you need a config file that is different from the production config file, you probably can and probably should setup a script/Makefile/Magic_Incantation which can generate the appropriate config file for development or production, and then version control that (instead of the config file). If on the other hand you are only varying the config file because you want to try something out, well I have known plenty of engineers who do that, and because it is something non-standard and probably only vaguely needed (i.e. no one else is going to need the config that way) they deal with the fact that they must do things by hand to keep their 'interesting config' from ending up in version control. if on the third hand (hey, where'd that come from?) each engineer needs their own config that does not change often and it for some reason can not be tweaked to the specific setup by a build script probably_bad_suggestionyou could each branch your version of the config file and not worry about the fact that it is under version control/probably_bad_suggestion. -- __ I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
Wade Williams wrote: I can't imagine I'm the only developer that makes local changes to try something out, but wants to be sure those changes do not end up in the repository. You're not the only developer that has had to deal with a problem like this. I agree with others who have said that allowing CVS to circumvent its own controls is not a wise idea. My advice is to be more specific when you commit. You don't need to commit from the top-level of your project. You likely already know where you made changes you do want to commit. If you've arranged your tree well, this configuration file should be somewhere else. In this case, commit closer to the real changes and CVS won't try to also commit your configuration changes. If you happen to make changes in the same place as the configuration file, then commit files one by one. -- Steve Madsen [EMAIL PROTECTED] Tadpole Computer, Inc. http://www.tadpole.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
On Wed, Apr 02, 2003 at 12:28:48AM -0600, Wade Williams wrote: But is there a way I can tell CVS - always update this file on an update, but ignore my changes on a commit? No, but you can get part-way there, by explicitly updating to the HEAD revision of the file. Find out what the HEAD revision is (for the sake of argument, say it's 1.4), and type: cvs update -r1.4 myfile Then, attempts to commit the file will die with this message: cvs commit: sticky tag `1.4' for file `myfile' is not a branch cvs [commit aborted]: correct above errors first! It doesn't do what you want automatically, but at least it gives you a noisy reminder to do it manually, and prevents CVS from doing the wrong thing if you forget. Unfortunately, updates will not update/merge the file; they'll update everything else and silently leave that one alone. You'll have to remember to periodically update it yourself: # Merge changes cvs update -A myfile # Don't change the file, but pin it at the new HEAD rev. cvs update -rnew-head-rev myfile That's the cost of using a sticky revision tag for its usually-annoying side effect, rather than for its intended purpose :-) CVS should probably print a warning in this case, but it doesn't. So this trick only gives you one of your two requirements, but arguably the more important one. The mistake it prevents you from making is the one that would affect other peoples' work, while the mistake it still permits will affect only your own. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
Eric Siegerman writes: CVS should probably print a warning in this case, but it doesn't. This case is updating a file with a sticky tag or date, which seems like a good idea to me, too. Anyone disagree? -Larry Jones Is it too much to ask for an occasional token gesture of appreciation?! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
On Wed, Apr 02, 2003 at 02:01:30PM -0500, Larry Jones wrote: Eric Siegerman writes: CVS should probably print a warning in this case, but it doesn't. This case is updating a file with a sticky tag or date, which seems like a good idea to me, too. Anyone disagree? Sticky *revision* tag or date (which is what I'm sure you meant :-). Issue: should CVS always complain, or only when it would actually have done something? The two options are: a. print a warning if a sticky revision tag or date is encountered during cvs update b. Like (a), but only if the revision named by that tag/date is different from the one CVS would otherwise have updated to Personally, I'd much prefer (b). If the sticky tag/date names the revision I'd have gotten anyway, then the end state I was requesting has been achieved; my sandbox is indeed up to date. It's only if the tag/date has prevented me from synchronizing completely that I need to make a decision. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Ignore local changes?
Eric Siegerman writes: CVS should probably print a warning in this case, but it doesn't. This case is updating a file with a sticky tag or date, which seems like a good idea to me, too. Anyone disagree? -Larry Jones I agree. A warning like cvs update myproject ... myfile.c skipped: remove sticky tag x to update ... Would be very useful. How does this suggestion become a formal feature request to the development team? - Brian ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
On Wed, Apr 02, 2003 at 01:09:44PM -0500, Todd Denniston wrote: if on the third hand (hey, where'd that come from?) each engineer needs their own config that does not change often and it for some reason can not be tweaked to the specific setup by a build script probably_bad_suggestionyou could each branch your version of the config file and not worry about the fact that it is under version control/probably_bad_suggestion. In this case, I typically make several files, and CVS-track those: httpd.conf-ERIC httpd.conf-SHIRLEY Or, back when CVS had options.h.in: options.h.in-FREEBSD options.h.in-LINUX options.h.in-SOLARIS What happens next depends on circumstances: - In both of the above examples, each sandbox then symlinks the appropriate variant into the working location. If it's a third-party package, I still CVS-track the un-suffixed real file -- httpd.conf or whatever -- but only for vendor updates and for local changes that should apply to all sandboxes. The trick I just posted about would be useful here -- setting a sticky revision tag on the real file to prevent accidental commits. I'll have to try that myself the next time the issue comes up :-) - Sometimes, the per-user files aren't hand-edited copies of the real file, but instead contain parameters to be substituted into a generic template. In that case, no symlink is made, but people (or the build system) have to rerun the template-substituter when the template or a user's per-sandbox parameters file has changed. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / A distributed system is one on which I cannot get any work done, because a machine I have never heard of has crashed. - Leslie Lamport ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
[ On Wednesday, April 2, 2003 at 13:44:00 (-0500), Eric Siegerman wrote: ]
Subject: Re: Ignore local changes?
No, but you can get part-way there, by explicitly updating to
the HEAD revision of the file. Find out what the HEAD revision
is (for the sake of argument, say it's 1.4), and type:
cvs update -r1.4 myfile
That's a really good suggestion Eric!
It is perhaps the only other good reason to ever use sticky revisions!
(the first reason is of course to simply avoid repository changes)
So this trick only gives you one of your two requirements, but
arguably the more important one. The mistake it prevents you
from making is the one that would affect other peoples' work,
while the mistake it still permits will affect only your own.
I've always wondered if maybe there shouldn't be an indicator of sticky
files (specifically only those with sticky revisions, not sticky branch
tags), such as maybe 'S':
$ cvs update
S newfile.c
Of course if it really is modified locally then you will see that
indicated even with no new hacks:
$ cvs update
M newfile.c
But maybe it should have a different flag letter anyway... ('m'?)
Maybe we also need a second new flag to indicate a modified sticky file
that's also out-of-date, i.e. like 'J' but for sticky files? An 'S'
overstruck with a 'J' looks a bit like an '8' :-) (but 'j' would
work for me too! ;-)
Then of course we'd need a third new flag for sticky unmodified files
that are just out of date. ('u'?)
Right now the worse problem is that 'cvs status' doesn't show the truth
about the current repository revision of a sticky file (at least it
doesn't in 1.11.1.1 -- maybe I should upgrade! ;-):
$ cvs status newfile.c
===
File: newfile.c Status: Up-to-date
Working revision:1.1 Sat Mar 16 20:10:40 2002
Repository revision: 1.1 /cvs/test/tdoc/newfile.c,v
Sticky Tag: 1.1
Sticky Date: (none)
Sticky Options: (none)
$ cd -
/home/proven/woods/tmp/t-tdoc2
$ cvs status newfile.c
===
File: newfile.c Status: Up-to-date
Working revision:1.2 Wed Apr 2 20:07:39 2003
Repository revision: 1.2 /cvs/test/tdoc/newfile.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
--
Greg A. Woods
+1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED]
Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED]
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Ignore local changes?
[ On Wednesday, April 2, 2003 at 13:51:42 (-0600), Brian G. Peterson wrote: ] Subject: RE: Ignore local changes? Eric Siegerman writes: CVS should probably print a warning in this case, but it doesn't. This case is updating a file with a sticky tag or date, which seems like a good idea to me, too. Anyone disagree? -Larry Jones I agree. A warning like cvs update myproject ... myfile.c skipped: remove sticky tag x to update ... Would be very useful. How does this suggestion become a formal feature request to the development team? I think warnings like this are generally less useful and are more confusing than simple status indicators. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
On Wed, 2 Apr 2003, Larry Jones wrote: Date: Wed, 2 Apr 2003 14:01:30 -0500 (EST) From: Larry Jones [EMAIL PROTECTED] To: Eric Siegerman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Ignore local changes? Eric Siegerman writes: CVS should probably print a warning in this case, but it doesn't. This case is updating a file with a sticky tag or date, which seems like a good idea to me, too. Anyone disagree? I agree conditionally. If you have many files (for instance all of them!) sticky to a revision, you don't want a separate warning for each file. What if they are all sticky? Proposal: issue a warning only for those files which are sticky to something different from what their containing directory is sticky to. Examples: 1. The directory ``x'' is sticky to ``foo_branch'' but files ``x/a'' and ``x/b.c'' are sticky to versions 1.3 and 1.9 respectively. The update operation over the directory warns in this case for these two files. 2. The directory ``x'' is sticky to ``foo_release_1'' but files ``x/a'' and ``x/b.c'' are not sticky to anything. Update over the directory does update these two files, but produces a warning. 3. The directory ``x'' on the main trunk, but files ``x/a'' and ``x/b'' are sticky to ``foo_branch''. Update warns for both. 4. The directory ``x'' is sticky, and ``x/b'' is not sticky. The user selectively updates ``x/b''. No warning. 5. The directory ``x'' is sticky to something, and ``x/b'' is sticky to something else. The user selectively updates ``x/b''. No warning. 6. The directory ``x'' is not sticky, and ``x/b'' is sticky. The user selectively updates ``x/b''. No warning. 7. The directory, and all its files, are sticky to the same tag, ``release_1_0''. Update does nothing, and produces no warning. Alternative: update warns that nothing is being done because of the sticky tag. Basically any situation in which the stickiness of a file contradicts the stickiness of the directory should be a cause for warning on update. A commit, if otherwise allowed, should probably fail because of this: the user should be forced to commit the differently-sticky files individuall. Example: 8. The directory ``x'' is sticky to branch ``foo'' and ``x/b'' is sticky to branch ``bar''. User commits in the directory. The commit fails, explaining the stickiness conflict---that the commit would be split into two or more branches. 9. The directory ``x'' is sticky to branch ``foo'' and ``x/b'' is sticky to branch ``bar''. User commits ``x/b'' selectively. The commit proceeds normally. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Ignore local changes?
Always, and only ever, modify a copy of any file if you don't want CVS to see your changes to it! I can't imagine I'm the only developer that makes local changes to try something out, but wants to be sure those changes do not end up in the repository. Maybe you could setup your system that on every update (at least of this file) it makes a copy of the checked out file. You would then work with the copy and on commit the original file is still intact. And on next update your local changes get overwritten again. That way your changes don't get committed (well, you looe all of them) but you still get updates to the file. If your app expects a special name for this file you need to rename it for cvs (like myfile_template or myfile_original) so the generated copy can have the expected name. bye Fabi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Ignore local changes?
I've got a file which I must make changes to on my system. However, I don't ever want my changes put back into the repository. Currently, I handle this by removing the file and re-updating the file from the repository before doing a commit. But is there a way I can tell CVS - always update this file on an update, but ignore my changes on a commit? Thanks, Wade ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
