Re: Stopping a modified file from being checked in
>--- Forwarded mail from [EMAIL PROTECTED] >On Sat, 13 Dec 2003, Paul Sander wrote: >>>I want to affect HEAD, just not for this one file. Making a branch >>>would be a bit silly if I will never commit anything on that >>>branch. >> >>Not at all. Isolating your work from that of your peers is what >>branches are all about. >But I can't create a branch without affecting the central repository, >I believe. So it's not completely isolating. It's true that the existence of the branch is recorded in the repository, and its sprout point is recorded in the affected RCS files. There's a difference between "isolating" your work and "hiding" your work. Isolating your work keeps it separate from others, while hiding it goes further to make it invisible. Branches are good at isolation. The only way to hide your work is to keep it local to your working directory. That's obviously your point, but on the other hand is it really necessary to hide the fact that you need local mods to that file? Something else to consider is this: If you find a need to tune your product locally, then so will your customers. This is a sign that your product might not have the degree of configurability that is really needed. Consider implementing an additional per-user configuration method (e.g. environment variables, or an additional profile file identified by an environment variable) to provide the capability. If that's not feasible, then consider wrapping your product in a script that generates the profile file from multiple sources, then launches the product using the generated file. >If I did make a branch, could I do so for one file, keeping everything >else on the trunk? Will it still be easy to update the one file with >changes from the trunk? When you run "cvs tag -b" and specify the file on the command line, the branch tag will affect only that file. Someone could apply that tag to another file in the future, of course. But if that's not intended then something needs to be done about project management to make sure that branch tags are never reused. When you run "cvs update -r" and specify the file on the command line, the sticky tag for only that file will be updated. When you need to merge that file from the HEAD at a later time, use "cvs update -j" as needed. This should solve your problem quite nicely. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Stopping a modified file from being checked in
>Peter Connolly <[EMAIL PROTECTED]> writes: >>>I would like to make some changes to a file in my working copy, but >>>definitely not check them in. >> >>If you don't want to accidently effect HEAD, why don't you do your >>changes on a branch? >I want to affect HEAD, just not for this one file. Making a branch >would be a bit silly if I will never commit anything on that branch. Not at all. Isolating your work from that of your peers is what branches are all about. >--- End of forwarded message from [EMAIL PROTECTED] Agreed. That's exactly what branches are for. Word to the wise... Anytime you find yourself standing on your head to do something like this, you're probably not using the tool the way that it was intended to be used. ;-) 'Nuff said. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Stopping a modified file from being checked in
>--- Forwarded mail from [EMAIL PROTECTED] >Peter Connolly <[EMAIL PROTECTED]> writes: >>>I would like to make some changes to a file in my working copy, but >>>definitely not check them in. >> >>If you don't want to accidently effect HEAD, why don't you do your >>changes on a branch? >I want to affect HEAD, just not for this one file. Making a branch >would be a bit silly if I will never commit anything on that branch. Not at all. Isolating your work from that of your peers is what branches are all about. >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Stopping a modified file from being checked in
Peter Connolly <[EMAIL PROTECTED]> writes: >>I would like to make some changes to a file in my working copy, but >>definitely not check them in. > >If you don't want to accidently effect HEAD, why don't you do your >changes on a branch? I want to affect HEAD, just not for this one file. Making a branch would be a bit silly if I will never commit anything on that branch. -- Ed Avis <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Stopping a modified file from being checked in
Hi! Why don't you just copy the file to another folder and make the CVS files uneditable. Then, when you copy the same to the CVS folder, it will be commitable and you can continue working on the local copy without any fear of making a wrong commit. Gagneet > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Ed Avis > Sent: Saturday, 13 December, 2003 2:39 AM > To: [EMAIL PROTECTED] > Subject: Stopping a modified file from being checked in > > > I would like to make some changes to a file in my working > copy, but definitely not check them in. Of course I wouldn't > deliberately run 'cvs commit', and I normally read through > diffs before checking in a change, but still I'm paranoid > that I might run 'cvs commit' in a parent directory and > accidentally check in my local changes. > > I'd like to mark the file so that it will not be committed. > I could do this by setting a sticky tag, but then 'cvs > update' will not merge changes into this file. Is there a > way I can mark a file to be updated _from_ the repository, > but not (until I deliberately unmark > it) to be committed _to_ the repository? > > -- > Ed Avis <[EMAIL PROTECTED]> > > > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs > ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Stopping a modified file from being checked in
> What I'd like is some error when I try to commit this one file. Well...probably the simplest (although it doesn't generate an error message) is to delete the file's entry from the CVS/Entries file in that file's current directory. CVS won't identify it as an updated file; it will think it's a new file requiring a 'cvs add...' and will leave it alone when you do commits. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Stopping a modified file from being checked in
Ed Avis writes: > > I'd like to mark the file so that it will not be committed. I could > do this by setting a sticky tag, but then 'cvs update' will not merge > changes into this file. Is there a way I can mark a file to be > updated _from_ the repository, but not (until I deliberately unmark > it) to be committed _to_ the repository? Set a sticky date some time in the future. -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Stopping a modified file from being checked in
On Fri, Dec 12, 2003 at 09:08:55PM +, Ed Avis wrote: > Is there a way I can mark a file to be > updated _from_ the repository, but not (until I deliberately unmark > it) to be committed _to_ the repository? If you're on the trunk, "cvs update -rHEAD file" should do it (awful kludge, but if it works...). If you're on a branch, I don't know of a way; as you suggested, "cvs update -r file" gets you half-way there, but you have to remember to update it manually. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / It must be said that they would have sounded better if the singer wouldn't throw his fellow band members to the ground and toss the drum kit around during songs. - Patrick Lenneau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Stopping a modified file from being checked in
> I would like to make some changes to a file in my working copy, but > definitely not check them in. If you don't want to accidently effect HEAD, why don't you do your changes on a branch? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
