enabling log.pl
This is what is the entry in my loginfo file ALL (echo ""; date; cat) | /usr/local/cvsroot/CVSROOT/log -u $USER -s -m [EMAIL PROTECTED] And when i try to do some commit this is what i get :( [EMAIL PROTECTED] CVSROOT]$ cvs commit temp.txt Checking in temp.txt; /usr/local/cvsroot/CVSROOT/temp.txt,v <-- temp.txt new revision: 1.10; previous revision: 1.9 done Could not open(): No such file or directory sh: line 1: : command not found cvs server: Rebuilding administrative file database ~Parvinder ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
[slightly OT] Re: best production practice?
Hi, A pragmatic way to do it is to do put updates on the server using: cvs co -rRELEASE_20 proj Then, ... To make a quick fix, get the latest source code on your dev environment, bump up the version number in your dev environment (even on your local machine running apache/iis/whatever). Tag it using cvs rtag, then do an rdiff to examine changes. Go through any change procedure (which for a single textbox caption should not be too onerous). Then, update the production server using: cvs up -rRELEASE_21 It shouldn't be too hard. The key is to make sure there is an easy place to edit the site in a dev environment. So, for a start -- don't version control the database config files or you'll have pain where prod and dev are fighting over which database connection to use. People can then go up and fiddle with the labels in 5 seconds -- but it doesn't show up to customers until you hit the big button. If you make it easy for people they shouldn't complain. You definitely want a release controlled environment, but at the same time, a system which involves lots of work just to change a single line of code is problematic and needs to be automated at some level (the grunt work, not the decisions, that is). Another thing -- don't be shy about creating versions: there's no problem with making several hundred versions which include nothing more than minor fixes to things here and there. Given that, no prob in making a script which fetches all tags, gets the highest release number, tags the next increment, and spits out a diff and patchset onto the desktop. People will love you for it. :) My 5 new/250 old francs, Cheers, Matthew Herrmann --- Far Edge Pty Ltd http://www.faredge.com.au/ Level 6, 35 Chandos Street St Leonards 2065 Ph: +612 8425 1400 -Original Message- bobby temper wrote: > > Hello, > > Thanks for the answers. > > I also agree with Jim, but it might be hard to convince content people that > they have to go throught a staging first, for simple stuff. I will definitly > do whatever i can, tho :). > > Todd, what you're saying refers actually to what i'm asking: the production > code is a checked out copy? (with the cvs folders, etc...). We already have > a tag/branch procedure. The problem is, as now, we have a "cvs export" copy > on production (and no cvs client on production either...). I'm wondering if > it would be better to install a cvs client, and have the code being a "cvs > checkout" copy. That way, we could do like you're proposing, with cvs diff. > I'm actually just wondering if doing it that way has some drawbacks, vs > doing a "cvs export/tar-gzip/scp" procedure. OUCH. OK, I am sometimes considered an SOB by those that work with me when it comes to releases, but it sounds like it is time for 1) the production machine to have the number of user names reduced to root+otherinstalleddefaultusers & projectadmin or 2) the production area locked down so only root & project admin can make modifications. If I was the person who had to answer "what is in the production machine today?", I would make three documents document 1) I, [my name], have permission to [insert lock down method] the production [machine|area], and anyone who subverts that gets [insert appropriate punishment]. This will be implementing an industry best practice [site sources (besides/in addition to Jim & me)][1] boss_signature_hereDate. document 2) I, [my name], am not responsible for the content of the production machine even though it has been suggested to customers we have someone in that job. boss_signature_hereDate. document 3) I, [my name], have informed [boss's name] that the production [machine|area], is out of control, and anyone with [insert level of access] can modify it at will and the changes will not be recorded in version control, so we can not track who or when a change was made. I, [my name], have informed [boss's name] of the following method for correcting the situation and been denied. [insert method(s) here] boss_signature_hereDate. I would then take them to my boss, and indicate s/he should pick one and sign it. BTW I am camping as physically close to my boss's person as is possible during working hours until one is signed. :) 1 gets you the ability to fix the problem. 2 indicates it should not be your butt that is the one to kick if there is a problem with what is on the production machine/area. 3 indicates the boss's butt is the one to kick _if/WHEN_ there is a problem with what is on the production machine/area. If the boss refuses to sign any of them... 1) email the concerns and fixes to the boss, and print a copy. 2) keep a note book recording the documents, the email & when they were presented. 3) consider if it is worth going to the boss's boss with the notebook. Sometimes you just have to drop back to these kind of strong arm tactics to get what is needed, and keep your own head. if the boss picks #1 (this is what you hop
Re: Generating patches by diff'ing the current repository state with a
Tate Austin writes: > > This is a multi-part message in MIME format. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! > Hey, I have a CVS server we are trying to do is to specialize a release > a bit, have the repository find the difference between what is currently > on it and what the last version tag was. Then generate a patch based on > that? So the idea being that every time we perform a release, it marks > that release in CVS and so the next release it finds the difference > between the current files and the state the files were in at the last > tag in the cvs repository? Is this something cvs is capable of doing by > default? (i'm new to using it beyond a distant file repository purpose) It won't do it by itself, but it's quite easy to do: cvs rtag V1 mystuff (work on stuff for next release) cvs rtag V2 mystuff cvs patch -rV1 -rV2 mystuff >mystuff_V2.patch (work on stuff for next release) cvs rtag V3 mystuff cvs patch -rV2 -rV3 mystuff >mystuff_V3.patch (etc.) -Larry Jones They can make me do it, but they can't make me do it with dignity. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Generating patches by diff'ing the current repository state w ith a tagged release.
Tate Austin wrote: > version tag was. Then generate a patch based on that? So the > idea being that every time we perform a release, it marks > that release in CVS and so the next release it finds the > difference between the current files and the state the files > were in at the last tag in the cvs repository? Is this > something cvs is capable of doing by default? (i'm new to > using it beyond a distant file repository purpose) Check out... er, that is, have a look at taginfo - it may do what you want: https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_18.html#SEC177 -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Generating patches by diff'ing the current repository state with a tagged release.
Title: Message Hey, I have a CVS server we are trying to do is to specialize a release a bit, have the repository find the difference between what is currently on it and what the last version tag was. Then generate a patch based on that? So the idea being that every time we perform a release, it marks that release in CVS and so the next release it finds the difference between the current files and the state the files were in at the last tag in the cvs repository? Is this something cvs is capable of doing by default? (i'm new to using it beyond a distant file repository purpose) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How to Setup CVSROOT/modules Question
Title: Message In my case, I, as cvs admin, don't let users touch the ../CVSROOT directory. To set up the CVSROOT/modules for your user, do... > cvs co CVSROOT/modules > cd CVSROOT Add the following line in the CVSROOT/modules file modulename -a dir1 dir2 file1 file2 dir3/file3 > cvs commit modulename, dir1, file1, etc. are of course the module name you want, and the files and dirs you want to include. Your user can then > cvs co modulename and get what you specified in the modules file -chris -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wang, Mary YSent: Thursday, February 10, 2005 2:23 PMTo: info-cvs@gnu.orgSubject: How to Setup CVSROOT/modules Question Hi All, I was able to set up a CVS repository for my users and I'm very new in CVS. One user mentioned that he wants CVSROOT/modules capability to be working so that he can fetch a list of modules in the CVS repository. I have read some where this should be done by the user. Is this capability should be setup by an admin? If so, how do I do that? He access the CVS repository via TortoiseCVS client program. I'm really lost. Any inputs is appreciated. ThanksMary ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
How to Setup CVSROOT/modules Question
Title: Message Hi All, I was able to set up a CVS repository for my users and I'm very new in CVS. One user mentioned that he wants CVSROOT/modules capability to be working so that he can fetch a list of modules in the CVS repository. I have read some where this should be done by the user. Is this capability should be setup by an admin? If so, how do I do that? He access the CVS repository via TortoiseCVS client program. I'm really lost. Any inputs is appreciated. ThanksMary ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can I turn off merge conflict markers?
Still another method, not for the faint at heart, is to apply my patch
from September 2001 that allows a site to install their own merge
tools. Perhaps even easier would be to read the name of the diff3
program from an environment variable. Then install a wrapper that does
what you want.
On Feb 10, 2005, at 9:08 AM, [EMAIL PROTECTED] wrote:
Todd Denniston wrote:
"Mark E. Hamilton" wrote:
[EMAIL PROTECTED] wrote:
When you get a file where automatic merge fails
CVS will report a merge conflict and then modify
the offending file with conflict markers:
...which is fine most of the time, but now I have a situation
I believe Mark's responses are correct, but you might be able to use
some
other commands to deal with it the way you want.
1. make separate lists of files with and without conflicts (look for
C in
the output of update).
cvs -n update 2>&1 | \
process_to_separate_filenames_with_conflicts 2. just update those
without conflicts.
for i in `cat files_without_conflicts`; \
do cvs update $i;done
3. do something special for the ones with conflicts.
for i in `cat files_with_conflicts`; \
do marks_method_1or2 $i;done
marks_method_3 is the only known correct method, but your situation
might be
special.
A fourth approach would be to do the 'cvs update' to merge everything
that can be merged successfully, and then use something like this to
automatically select one of the two choices in the conflict lines:
#!/bin/bash
for file in $(cvs -q update | egrep '^C' | cut -f2 -d' ')
do
# Pick one of these two sed commands.
# This will discard the repository changes and keep the project changes
sed -e '/^===/,/^>>>/d' -e '/^<< blarg \
&& mv blarg ${file}
# This will discard the project changes and keep the respository
changes
sed -i -e '/^<<>>/d' ${file} > blarg \
&& mv blarg ${file}
done
--
Mark E. Hamilton
Orion International Technologies, Inc.
Sandia National Laboratory, NM.
844-7666
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
--
Paul Sander | "To do two things at once is to do neither"
[EMAIL PROTECTED] | Publilius Syrus, Roman philosopher, 100 B.C.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Restrict a user to make any changes in HEAD
cvs_acls is in the contrib directory of the source for CVS https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.html ~Matt > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: Thursday, February 10, 2005 4:12 AM > To: info-cvs@gnu.org > Subject: Restrict a user to make any changes in HEAD > > Hi , > > > > I need to restrict a particular user to make any changes in > the main trunk i.e. he cannot commit any changes made in a > file on the HEAD trunk. How can I lock the main trunk to that > particular user. > > > > Regards, > > Ramanuj Singh > > > > The information transmitted is intended only for the person > or entity to whom it is addressed and may contain > confidential and / or privileged Material. Any review, > re-transmission, dissemination or other use of or taking of > any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and > delete the material from your computer. Thank you for your > understanding & co-operation. > > > > ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
[slightly OT] Re: best production practice?
bobby temper wrote: > > Hello, > > Thanks for the answers. > > I also agree with Jim, but it might be hard to convince content people that > they have to go throught a staging first, for simple stuff. I will definitly > do whatever i can, tho :). > > Todd, what you're saying refers actually to what i'm asking: the production > code is a checked out copy? (with the cvs folders, etc...). We already have > a tag/branch procedure. The problem is, as now, we have a "cvs export" copy > on production (and no cvs client on production either...). I'm wondering if > it would be better to install a cvs client, and have the code being a "cvs > checkout" copy. That way, we could do like you're proposing, with cvs diff. > I'm actually just wondering if doing it that way has some drawbacks, vs > doing a "cvs export/tar-gzip/scp" procedure. OUCH. OK, I am sometimes considered an SOB by those that work with me when it comes to releases, but it sounds like it is time for 1) the production machine to have the number of user names reduced to root+otherinstalleddefaultusers & projectadmin or 2) the production area locked down so only root & project admin can make modifications. If I was the person who had to answer "what is in the production machine today?", I would make three documents document 1) I, [my name], have permission to [insert lock down method] the production [machine|area], and anyone who subverts that gets [insert appropriate punishment]. This will be implementing an industry best practice [site sources (besides/in addition to Jim & me)][1] boss_signature_hereDate. document 2) I, [my name], am not responsible for the content of the production machine even though it has been suggested to customers we have someone in that job. boss_signature_hereDate. document 3) I, [my name], have informed [boss's name] that the production [machine|area], is out of control, and anyone with [insert level of access] can modify it at will and the changes will not be recorded in version control, so we can not track who or when a change was made. I, [my name], have informed [boss's name] of the following method for correcting the situation and been denied. [insert method(s) here] boss_signature_hereDate. I would then take them to my boss, and indicate s/he should pick one and sign it. BTW I am camping as physically close to my boss's person as is possible during working hours until one is signed. :) 1 gets you the ability to fix the problem. 2 indicates it should not be your butt that is the one to kick if there is a problem with what is on the production machine/area. 3 indicates the boss's butt is the one to kick _if/WHEN_ there is a problem with what is on the production machine/area. If the boss refuses to sign any of them... 1) email the concerns and fixes to the boss, and print a copy. 2) keep a note book recording the documents, the email & when they were presented. 3) consider if it is worth going to the boss's boss with the notebook. Sometimes you just have to drop back to these kind of strong arm tactics to get what is needed, and keep your own head. if the boss picks #1 (this is what you hope for), you can implement the corrective change ... tell the complaining people "the boss indicated it should be done", and (to relieve some of the stress you just applied to his/her arm) tell the boss to tell them "we are implementing industry best practices...(pause to see if they complain more, if so finish with) you will work with it. If you do not feel it is best practice, document why, and site your sources." before they show up in the bosses office. > > Regards, > Bobby > [1] you could start by searching the mailing list for other people dealing with release management http://www.cmcrossroads.com/bradapp/acme/ http://www.cmcrossroads.com/bradapp/acme/#BuildRepro http://www.cmcrossroads.com/bradapp/acme/repro/SoftwareReconstruction.html http://lists.gnu.org/pipermail/info-cvs http://www.google.com/search?hl=en&q=release+managment&btnG=Google+Search http://www.google.com/search?hl=en&lr=&q=%22release+managment%22+CVS&btnG=Search http://www.google.com/search?hl=en&lr=&q=%22release+management%22&btnG=Search http://www.google.com/search?hl=en&lr=&q=%22release+management%22+CVS&btnG=Search http://www.google.com/search?hl=en&lr=&q=%22release+management%22+%22best+practices%22&btnG=Search http://www.google.com/search?hl=en&lr=&q=%22release+management%22+%22best+practices%22+cvs+-pvcs&btnG=Search http://www.w3.org/OOP/9606_Workshop/submissions/31-W3COMG.html http://www.wipro.com/prodesign/focusareas/complatforms/complatpcasestudy8.htm you get the picture right? -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: best production practice?
bobby temper wrote: > I also agree with Jim, but it might be hard to convince > content people that > they have to go throught a staging first, for simple stuff. In my experience, it's usually the simple stuff that causes the most headaches ;=) > I'm wondering if > it would be better to install a cvs client, and have the code > being a "cvs > checkout" copy. That way, we could do like you're proposing, > with cvs diff. > I'm actually just wondering if doing it that way has some > drawbacks, vs > doing a "cvs export/tar-gzip/scp" procedure. The drawback would be having to administer another installation of a cvs client. Not much overhead, I think. One advantage - you can check in changes directly from any production hot-fixes. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can I turn off merge conflict markers?
Mark E. Hamilton wrote:
A fourth approach would be to do the 'cvs update' to merge everything
that can be merged successfully, and then use something like this to
automatically select one of the two choices in the conflict lines:
#!/bin/bash
for file in $(cvs -q update | egrep '^C' | cut -f2 -d' ')
do
# Pick one of these two sed commands.
# This will discard the repository changes and keep the project changes
sed -e '/^===/,/^>>>/d' -e '/^<< blarg \
&& mv blarg ${file}
# This will discard the project changes and keep the respository changes
sed -i -e '/^<<>>/d' ${file} > blarg \
&& mv blarg ${file}
done
Whoops, major typo. In the second sed() command DON'T use the '-i'
option with the redirect; you'll end up with an empty file. Sorry.
sed -e '/^<<>>/d' ${file} > blarg \
&& mv blarg ${file}
FWIW, if your sed() supports the '-i' option you don't need to do the
redirect and move.
--
Mark E. Hamilton
Orion International Technologies, Inc.
Sandia National Laboratory, NM.
844-7666
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can I turn off merge conflict markers?
Todd Denniston wrote:
"Mark E. Hamilton" wrote:
[EMAIL PROTECTED] wrote:
When you get a file where automatic merge fails
CVS will report a merge conflict and then modify
the offending file with conflict markers:
...which is fine most of the time, but now I have a situation
I believe Mark's responses are correct, but you might be able to use some
other commands to deal with it the way you want.
1. make separate lists of files with and without conflicts (look for C in
the output of update).
cvs -n update 2>&1 | \
process_to_separate_filenames_with_conflicts
2. just update those without conflicts.
for i in `cat files_without_conflicts`; \
do cvs update $i;done
3. do something special for the ones with conflicts.
for i in `cat files_with_conflicts`; \
do marks_method_1or2 $i;done
marks_method_3 is the only known correct method, but your situation might be
special.
A fourth approach would be to do the 'cvs update' to merge everything
that can be merged successfully, and then use something like this to
automatically select one of the two choices in the conflict lines:
#!/bin/bash
for file in $(cvs -q update | egrep '^C' | cut -f2 -d' ')
do
# Pick one of these two sed commands.
# This will discard the repository changes and keep the project changes
sed -e '/^===/,/^>>>/d' -e '/^<< blarg \
&& mv blarg ${file}
# This will discard the project changes and keep the respository changes
sed -i -e '/^<<>>/d' ${file} > blarg \
&& mv blarg ${file}
done
--
Mark E. Hamilton
Orion International Technologies, Inc.
Sandia National Laboratory, NM.
844-7666
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: best production practice?
Hello, Thanks for the answers. I also agree with Jim, but it might be hard to convince content people that they have to go throught a staging first, for simple stuff. I will definitly do whatever i can, tho :). Todd, what you're saying refers actually to what i'm asking: the production code is a checked out copy? (with the cvs folders, etc...). We already have a tag/branch procedure. The problem is, as now, we have a "cvs export" copy on production (and no cvs client on production either...). I'm wondering if it would be better to install a cvs client, and have the code being a "cvs checkout" copy. That way, we could do like you're proposing, with cvs diff. I'm actually just wondering if doing it that way has some drawbacks, vs doing a "cvs export/tar-gzip/scp" procedure. Regards, Bobby From: Todd Denniston <[EMAIL PROTECTED]> To: "Jim.Hyslop" <[EMAIL PROTECTED]> CC: "'bobby temper'" <[EMAIL PROTECTED]>, info-cvs@gnu.org Subject: Re: best production practice? Date: Wed, 09 Feb 2005 17:18:36 -0500 "Jim.Hyslop" wrote: > > bobby temper wrote: > > What i meant is that, we have the code running on a > > production machine. Now > > and then, that code gets changed, and sometimes, it's content > > gets out of > > sync with whats on production (ie. for example. someone edit > > directly on > > production, for a hotfix (i know this is bad, but fast for > > changing a simple > > text, link, etc...) and forget to do the changes in cvs. > This practise *MUST* stop. Do whatever it takes to make it stop, otherwise > one day you *will* get burned, and badly. "Changing a simple text" is no > excuse. > > Problem solved. I agree with Jim that you must stop the practice, as it "*will* get burned", however Jim he still needs a method to DETECT violation of the integrity of the production set, for as long as he is still working with his bosses to get the policy fixed. for detection, the following might do it. if you use tags to checkout for a release, try `cd head/of/project/; cvs diff -rTagShownInThisSet`, if you get anything, a violation has occurred, attempt to find the violator and use a LART as necessary. without tags just using `cvs diff ` might get you started, if you get anything, a violation has occurred, attempt to find the violator and use a LART as necessary. Also without tags, it is time to talk to the boss and get the procedure changed at least to indicate releases shall be made only from tags. All Production releases should be if possible made by using your build system, or a release build system, to do a checkout, tag if the checkout was not of a tag, build & package, in this way you can be sure to be able to recreate releases. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter The opinions expressed here are not sanctioned by and do not necessarily represent those of my employer. _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can I turn off merge conflict markers?
"Mark E. Hamilton" wrote: > > [EMAIL PROTECTED] wrote: > > Can I set a cvs update option so that it will only > > report merge conflict files and NOT modify them with > > conflict markers? It does not appear that "cvs update" > > has an option like this, but maybe there is some trick > > someone can clue me in on. > > Probably not, but the CVS gurus here would know. > > > When you get a file where automatic merge fails > > CVS will report a merge conflict and then modify > > the offending file with conflict markers: > > > > > > > > ...which is fine most of the time, but now I have a situation > > where I'm working in a project with someone else's code > > and I'm getting a lot of these. The difference for these files > > are trivial. It's a lot of extra hassle to have to > > go delete all these conflict markers. It's sufficient for me to > > know there is a problem. I want to update what I can, but > > I don't want cvs to touch the conflicted files. > > I just want it to report them. > > As I see it you've really only got three choices: > > 1. cvs update -C foo.c > > This will replace the file with a fresh version from the repository, > discarding all the changes made in the sandbox version of the file, > including those that merged successfully (ie, didn't cause a conflict.) > Sometimes this is the right thing to do; you'll have to decide. > > 2. cp .#foo.c.x.y > > This will replace the updated version of the file with the version prior > to the update, discarding all the changes made in the repository version > of the file, including those that merged successfully (ie, didn't cause > a conflict.) This is almost never the right thing to do. > > 3. Deal with those pesky conflicts and edit them as necessary. > > This is the right thing to do. This is the only answer that will retain > any changes that were successfully merged. The caveat of course is that > you need to run your tests after the update, because even changes that > successfully merged might still be logically incorrect with the changes > made in the sandbox. > I believe Mark's responses are correct, but you might be able to use some other commands to deal with it the way you want. 1. make separate lists of files with and without conflicts (look for C in the output of update). cvs -n update 2>&1 | \ process_to_separate_filenames_with_conflicts 2. just update those without conflicts. for i in `cat files_without_conflicts`; \ do cvs update $i;done 3. do something special for the ones with conflicts. for i in `cat files_with_conflicts`; \ do marks_method_1or2 $i;done marks_method_3 is the only known correct method, but your situation might be special. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Restrict a user to make any changes in HEAD
Hi , I need to restrict a particular user to make any changes in the main trunk i.e. he cannot commit any changes made in a file on the HEAD trunk. How can I lock the main trunk to that particular user. Regards, Ramanuj Singh The information transmitted is intended only for the person or entity to whom it is addressed and may contain confidential and / or privileged Material. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Thank you for your understanding & co-operation. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Medium sized binaries, lots of commits and performance
Larry Jones wrote: >> I and the rest of us out here work with Oracle Forms and that means >> binary source code. > >Are you sure there isn't a way to store them as text or to convert them >to text? Source control systems are popular enough that there almost >certainly is. Storing them in text form rather than in binary >is by far the best solution to your potential problem. I absolutely sure there is such a way :) The Oracle Form Builder tool supports this innately. I'm a bit hesitant to go this way, however, because it complicates most people's lives here (having to always do explicit converting and all). Also, we pull source code directly from CVS (using a perl script) and compile our releases/launches from it - but your suggestion may of course make it far more expedient to pull everything as ascii files, convert to binaries, and then compile as usual. Your advice may well be implemented - if I don't successfully follow any of the other very fine suggestions by the people on this list. BTW, if I have a binary of 2.8 MB it converts to text format as 6,4 MB. Altbough the ascii is bigger I'm assuming CVS will be able to handle it more efficiently (smaller deltas). Thanks a lot for the advice! Regards, Jesper Vad Kristensen Aarhus, Denmark ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Medium sized binaries, lots of commits and performance
Paul and Doug, Thanks a lot for the advice (Larry too, but I replied to him elsewhere). You've given me plenty to go on. I believe it's up to me now to figure out what's most appropriate. Regards, Jesper Vad Kristensen Aarhus, Denmark ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
