Re: New feature in 1.19 compare to 1.11.1p1 version of CVS
Krishna Prasad MV [EMAIL PROTECTED] writes: Hi All, We are planning to upgrade our CVS server from 1.11.1p1 version to latest. And selected to use CVS version 1.19 or any latest. Now we wants know the features and any pros and cons in 1.19 above. Please suggest and update. http://www.cvshome.org/ for general information. See http://ccvs.cvshome.org/servlets/NewsItemView?newsID=60 for cvs 1.11.6 (stable release) announcement. An upgrade from 1.11.1p1 should be fairly painless. Lots of bugs and a few security problems have been fixed. See http://ccvs.cvshome.org/servlets/NewsItemView?newsID=61 for cvs 1.12.1 (development release) announcement. I am not aware of any '1.19' version of cvs. Good luck, -- Mark ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: New feature in 1.19 compare to 1.11.1p1 version of CVS
On 2003-08-22 13:24+0530 Krishna Prasad MV wrote: We are planning to upgrade our CVS server from 1.11.1p1 version to latest. And selected to use CVS version 1.19 or any latest. Now we wants know the features and any pros and cons in 1.19 above. Please suggest and update. Uh... 1.19? The latest stable version is 1.11.6 and the last feature release is 1.12.1 . If you want to run CVS in production use, 1.11.6 would be the version to use. Regards, yvind A. Holm 60.39494N 5.33016E Lbh unir qrpelcgrq zl fvtangher. Nppbeqvat gb gur QZPN, lbh ner abj n pevzvany. jjj.nagv-qzpn.bet ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
New feature in 1.19 compare to 1.11.1p1 version of CVS
Hi All, We are planning to upgrade our CVS server from 1.11.1p1 version to latest. And selected to use CVS version 1.19 or any latest. Now we wants know the features and any pros and consin 1.19 above. Please suggest and update. Thanks in advance KP ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
new feature.
Hi all I would like to know where is the better place to ask new feature to be added to CVS? Is there any mailing list or web page to do so? Thanks Marc Tessier [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: new feature.
Marc Tessier opined: I would like to know where is the better place to ask new feature to be added to CVS? Is there any mailing list or web page to do so? Well, this is as good a place as any. Would you like to describe the feature you'd like to see? -- Shankar ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: new feature.
(a) Please don't reply to individual list members - address yourself to the list itself, if you don't mind.. (b) Interesting idea, but why do you want to avoid tagging everything? The general recommended CVS usage model is that the repository be considered a whole entity. Thus, you tag the entire repository the way it should be for a particular release, whether it be a full release, or a partial delta. Extra tags on files cost almost nothing, and by properly maintaining your tags, you can re-generate your deltas trivially using cvs diff -rtag1 -rtag2, which will generate no output for files that have not changed between tag1 and tag2. Is this something you're already doing with another revision control system? I can't think of any commonly used revision control system that does the sort of thing you're asking - at least, not ClearCase or Perforce, which are the other two I've used extensively. I'd say it's a lot more error-prone to do selective tagging correctly than tagging the entire repository. CVS makes it simple to do things another way: * You keep a build workarea where you build and test your product. You can update any single or multiple files you need to fix problems you find during integration and testing. Or branch the files you want to modify. * When you're satisfied that the product built from your build area is release-ready, you tag it from the build area, which automatically tags the versions of the files that you have worked with in that build area. -Original Message- From: Marc Tessier [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 3:13 PM To: Shankar Unni Subject: RE: new feature. I would like to see a feature to extract the most recent revision of a file from a list of TAGs specified as a parameters. Like Tag A B C and the file rev in A is 1.10 and in C it's 1.12 so If a do a checkout or export of TAG A B and C I will get the most recent file that is 1.12 from TAG C. Some people work with CVS by tagging all the files but in my case I just want to work with delta. I do not need to resend to my people all files just need to send them delta so my packages are small all the time. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Shankar Unni Sent: Monday, March 24, 2003 1:33 PM To: 'CVS Mailing List' Subject: RE: new feature. Marc Tessier opined: I would like to know where is the better place to ask new feature to be added to CVS? Is there any mailing list or web page to do so? Well, this is as good a place as any. Would you like to describe the feature you'd like to see? -- Shankar ___ 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: new feature.
What Marc is describing is a different paradigm for change management. Systems such as Aide-de-Camp track features, and when you want a workspace you specify a set of features that you want. There are limitations to such a system, as you would expect, but it is viable approach. --- Forwarded mail from [EMAIL PROTECTED] (a) Please don't reply to individual list members - address yourself to the list itself, if you don't mind.. (b) Interesting idea, but why do you want to avoid tagging everything? [...] Is this something you're already doing with another revision control system? I can't think of any commonly used revision control system that does the sort of thing you're asking - at least, not ClearCase or Perforce, which are the other two I've used extensively. -Original Message- From: Marc Tessier [mailto:[EMAIL PROTECTED] I would like to see a feature to extract the most recent revision of a file from a list of TAGs specified as a parameters. Like Tag A B C and the file rev in A is 1.10 and in C it's 1.12 so If a do a checkout or export of TAG A B and C I will get the most recent file that is 1.12 from TAG C. Some people work with CVS by tagging all the files but in my case I just want to work with delta. I do not need to resend to my people all files just need to send them delta so my packages are small all the time. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: new feature.
Shankar Unni wrote:
SNIP
(b) Interesting idea, but why do you want to avoid tagging everything?
The general recommended CVS usage model is that the repository be
considered a whole entity. Thus, you tag the entire repository the way
it should be for a particular release, whether it be a full release, or
a partial delta.
Extra tags on files cost almost nothing, and by properly maintaining
your tags, you can re-generate your deltas trivially using cvs diff
-rtag1 -rtag2, which will generate no output for files that have not
changed between tag1 and tag2.
Is this something you're already doing with another revision control
system? I can't think of any commonly used revision control system that
does the sort of thing you're asking - at least, not ClearCase or
Perforce, which are the other two I've used extensively.
SNIP
while I agree with Shankar, that for most situations having the whole
repository tagged is the best method and for your situation I think it is
correct, I have found a use for tagging just some files.
When working with a mess of scripts used for testing a product, I found that I
had several 'engineers debug' scripts which needed controlled and could
eventually be used for THE test, but for each formal test it was decided that
only the scripts called out formally in the test description were to be
available to the testers (this removes the management worry that they are
running the just make it work backdoor scripts).
I found that if I had a file with a list of the filenames (one per line) used
in the formal test I could do a variation on the following (in bash):
BASE_SCRIPTS_DIR=path_to_checked_out_baseline
TAGNAME=My_Formal_tag
tagsome()
{
read INPUTLINE
while [[ $INPUTLINE != EOF ]]
do
#the following should tag each file individually so we only tag those we
#want to.
(cd $BASE_SCRIPTS_DIR/scripts;cvs tag -l $TAGNAME $INPUTLINE)
read INPUTLINE
done
}
tagsome list_of_the_filenames.txt
#the following would retrieve only the files that had the
#tag applied to them.
#I do not know if this is a 'known feature' of cvs, so it
#may change in the future.:)
cvs checkout -r$TAGNAME scripts
Note: how you get list_of_the_filenames.txt is your problem, I had to do
several contortions of `strings ?.doc|grep patterns|awk|perl_script` (Yes you
can program when you are just the CM person :)
-Original Message-
From: Marc Tessier [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 3:13 PM
To: Shankar Unni
Subject: RE: new feature.
SNIP
Some people work with CVS by tagging all the files but in my
case I just want to work with delta. I do not need to resend
to my people all files just need to send them delta so my
packages are small all the time.
SNIP
--
__
Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED]
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: new feature.
Todd Denniston wrote:
SNIP
BASE_SCRIPTS_DIR=path_to_checked_out_baseline
TAGNAME=My_Formal_tag
tagsome()
{
read INPUTLINE
while [[ $INPUTLINE != EOF ]]
do
#the following should tag each file individually so we only tag those we
#want to.
(cd $BASE_SCRIPTS_DIR/scripts;cvs tag -l $TAGNAME $INPUTLINE)
read INPUTLINE
done
}
Forgot one thing, kind of a got-ya when it hits :)
echo EOF list_of_the_filenames.txt
That is unless you like long running loops :)
tagsome list_of_the_filenames.txt
SNIP
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: new feature.
The general recommended CVS usage model is that the repository be considered a whole entity. Thus, you tag the entire repository the way it should be for a particular release, whether it be a full release, or a partial delta. I *think* you could define a module as having parts of all modules and then tagging that single module would tag everything in the CVS tree... http://www.cvshome.org/docs/manual/cvs_18.html#SEC157 C.1.1 Alias modules ... as if the list of names aliases had been specified instead. aliases may contain either other module names or paths. . Extra tags on files cost almost nothing, and by properly maintaining your tags, you can re-generate your deltas trivially using cvs diff -rtag1 -rtag2, which will generate no output for files that have not changed between tag1 and tag2. Is this something you're already doing with another revision control system? I can't think of any commonly used revision control system that does the sort of thing you're asking - at least, not ClearCase or Perforce, which are the other two I've used extensively. I'd say it's a lot more error-prone to do selective tagging correctly than tagging the entire repository. CVS makes it simple to do things another way: * You keep a build workarea where you build and test your product. You can update any single or multiple files you need to fix problems you find during integration and testing. Or branch the files you want to modify. * When you're satisfied that the product built from your build area is release-ready, you tag it from the build area, which automatically tags the versions of the files that you have worked with in that build area. -Original Message- From: Marc Tessier [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 3:13 PM To: Shankar Unni Subject: RE: new feature. I would like to see a feature to extract the most recent revision of a file from a list of TAGs specified as a parameters. Like Tag A B C and the file rev in A is 1.10 and in C it's 1.12 so If a do a checkout or export of TAG A B and C I will get the most recent file that is 1.12 from TAG C. Some people work with CVS by tagging all the files but in my case I just want to work with delta. I do not need to resend to my people all files just need to send them delta so my packages are small all the time. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Shankar Unni Sent: Monday, March 24, 2003 1:33 PM To: 'CVS Mailing List' Subject: RE: new feature. Marc Tessier opined: I would like to know where is the better place to ask new feature to be added to CVS? Is there any mailing list or web page to do so? Well, this is as good a place as any. Would you like to describe the feature you'd like to see? -- Shankar ___ 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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: new feature suggestion: 3-way conflict indicators
[ On Saturday, June 22, 2002 at 13:51:15 (+1000), Matthew Herrmann wrote: ] Subject: Re: new feature suggestion: 3-way conflict indicators but, if i were to include this as a new argument to cvs update as an argument (-3 i quite like), it wouldn't affect sanity.sh at all, since those scripts would run exactly as before I think the only proper way to display merge conflicts is with '-AT'. I think '-E' is bogus and misleading in almost all cases. (Note that '-A' doesn't show unnecessary duplication -- it only shows old and new if that's all that's necessary.) Further I think that if you expect '-A' format output then you don't ever want to even accidentally not produce it. Undoing and re-doing merges can be an extremely painful, and almost impossible, process. of course, it would probably be a good idea to include some sanity checks eventually. Strictly speaking the sanity checks would always be necessary, and they get one heck of a lot more complex if you make this a command-line option because now you need to add new checks instead of just fixing existing checks and if you've looked at sanity.sh I'm sure you'll agree that doing such is not a pretty job. I do have a working sanity.sh for my version of CVS, but it's somewhat dated. :-) (btw, -3 would be a less than ideal choice for an option letter. Option letters that are digits have been shown to confuse people, and also they're not strictly allowed by the POSIX command-line conventions.) -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [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: new feature suggestion: 3-way conflict indicators
Hi Greg, I just looked at sanity.sh (it's kind of scary when you mistake the test cases for code -- it looks like the obfuscated C competition on steroids!) and the CVS code itself, and there's a fair bit of disruption needed to get it a command-line parameter to the RCS_Merge command. i think i'll just take your suggestion, and patch our server with the -AT and be done with it. Thanks for the info about the no duplication, that means then that conflict markers will work well for both multi-developer-style merges and update-from-bugfix merges. I'll need to let the guys know here how the new system works but this will sure save me some headaches I can assure you! Many thanks, Matthew -Original Message- From: Greg A. Woods [mailto:[EMAIL PROTECTED]] Sent: Sunday, 23 June 2002 03:31 To: Matthew Herrmann Cc: CVS Mailing List Subject: Re: new feature suggestion: 3-way conflict indicators [ On Saturday, June 22, 2002 at 13:51:15 (+1000), Matthew Herrmann wrote: ] Subject: Re: new feature suggestion: 3-way conflict indicators but, if i were to include this as a new argument to cvs update as an argument (-3 i quite like), it wouldn't affect sanity.sh at all, since those scripts would run exactly as before I think the only proper way to display merge conflicts is with '-AT'. I think '-E' is bogus and misleading in almost all cases. (Note that '-A' doesn't show unnecessary duplication -- it only shows old and new if that's all that's necessary.) ... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: new feature suggestion: 3-way conflict indicators
but, if i were to include this as a new argument to cvs update as an argument (-3 i quite like), it wouldn't affect sanity.sh at all, since those scripts would run exactly as before of course, it would probably be a good idea to include some sanity checks eventually. If I wrote a patch to include the functionality with a -3 option to CVS, with following help: Usage: cvs update [-APdflRp] [-k kopt] [-r rev|-D date] [-j rev] [-I ign] [-W spec] [files...] ... -k kopt Use RCS kopt -k option on checkout. -r rev Update using specified revision/tag (is sticky). -D date Set date to update from (is sticky). -3 Include original text when marking conflicts. -j rev Merge in changes made between current revision and rev. -I ign More files to ignore (! to reset). ... then people could turn it on just when they were using cvs update -j, but it wouldn't give too much info when people were just editing in a normal context (where it is overkill since the original source on both people's working copies are usually close to identical) Would this be likely to be accepted into a new release? I mean, it doesn't sound particularly risky? It's just like allowing users to pass through parameters to the cvs diff command... it won't offend anyone, and i think my last email gave some pretty good reasons to why it _should_ be included. i'm d/l'ing the source now, i'll check out making a full patch that includes all the frills like the new command-line parameter. if it's straightforward enough, i'll check out updating sanity.sh (though this won't _need_ to be updated if i patch my way, it just _should_ be)... biggest prob here is i'm on a win2k box, linux is only on the server which makes things a bit trickier. rgds, matt On Tue, Jun 18, 2002 at 11:33:18PM -0400, Greg A. Woods wrote: [ On Wednesday, June 19, 2002 at 09:04:37 (+1000), Matthew Herrmann wrote: ] Subject: new feature suggestion: 3-way conflict indicators The core patch is (including some extra unrelated fixes): Without the unrelated fixes, it's a one-character change (this is from 1.11.1p1, but I doubt it's changed significantly for 1.11.2). Be warned though; this patch will make sanity.sh fail big-time. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
new feature suggestion: 3-way conflict indicators
Hi All,
I have a suggestion for a new feature I think would be exceedingly useful
for difficult merges. The idea is to have 3-way conflict indicators.
THE PROBLEM:
When I do a difficult merge, i sometimes usually go off an rdiff output
while i'm tracing through the conflicts to make sure i capture the changes
properly. I find this helpful determining changes causing conflicts.
But surely, shouldn't the conflict markers themselves be adequate to resolve
a merge? (and the reason they are thrown in in the first place?) Not so. I
believe that the current system of conflict markers is subtly (and
dangerously) inadequate, and lacks some vital information to resolve
conflicts safely.
THE EXAMPLE:
Let me give an example to demonstrate the problem, and my proposed
solution...
here we have a conflict in some code after performing a bugfix merge off a
production branch onto the development trunk, shown below. Looks simple?
Someone's obviously gone and changed the indenting (note the extra spaces)
in this part of the code because they put it in a for loop, which is why the
auto merger couldn't put in the 10 = 9 change, and the i = i+1 change.
FILE:
... rest of file
for (j=0; j100; j++) {
for (i=0; i10; i++) {
perform_operation(i+1);
}
---
for (i=0; i9; i++) {
perform_operation(i);
}
}
... rest of file
WRONG! The change was only to change i to i+1, but the 10 should not have
been changed! 10 had been changed to 9 in the trunk, but not on the branch,
and had been done that way for good reason. But now, we have clobbered our
trunk's code change from 10=9 (possibly now a new bug) with old code from
the bugfix branch. Incredible how such an innocent looking conflict can be
really nasty... Imagine all the bugs this could create. This shows the
fundamental weakness in using standard conflict markers to merge changes.
I reckon this weakness is the main reason why so many people on this list
(Greg for example) are horrified by code beautifiers, because they make this
kind of error really likely. Why? Not because code beautification is
inherently _dangerous_ (though some might say useless), but because it means
you need to perform conflict resolution using conflict markers, much more
often, which _are_ (IMHO).
THE SOLUTION:
How about this? Now it's obvious that the change was in fact to fix the
out-of-range error caused by i-1, and that the 9 - 10 difference was
because of something else.
OLD UNFIXED
for (i=0; i10; i++) {
! perform_operation(i);
}
FIXED -
for (i=0; i10; i++) {
! perform_operation(i+1);
}
---
for (i=0; i9; i++) {
perform_operation(i);
}
NEW UNFIXED
Now, the person merging would be very clear that only the i+1 was included
in the change, and would apply that (or something in the same 'spirit').
Please consider this, I think this would be a great idea and would add great
value to the concurrent edits model.
What do other people think? Anyone else agree, or disagree?
Note that that this effectively eliminates the _DANGER_ aspect out of the
problems in reformatting code in the trunk and causing nonsense conflicts.
It's now simply just _annoying_ and time consuming to the person merging,
rather than risking clobbering changes (although of course human error in
manual merges is still, as always, a factor, though i would argue now far
less likely, and certainly no more error prone than non-conflicting
automatic merges).
PS We have just installed the new version of CVS... thankyou to all those
who contributed, especially Larry for incorporating the -rR1::R2 request,
appreciated.
Regards,
Matthew Herrmann
--
Far Edge Technology
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: new feature suggestion: 3-way conflict indicators
[ On Wednesday, June 19, 2002 at 09:04:37 (+1000), Matthew Herrmann wrote: ]
Subject: new feature suggestion: 3-way conflict indicators
I have a suggestion for a new feature I think would be exceedingly useful
for difficult merges. The idea is to have 3-way conflict indicators.
I suggested the same, and provided full patches to implement them,
several years ago! ;-) See the archives. (I think...)
The core patch is (including some extra unrelated fixes):
$ cvs diff rcscmds.c
Index: rcscmds.c
===
RCS file: /home2/cvsroot/ccvs/src/rcscmds.c,v
retrieving revision 1.50
diff -c -r1.50 rcscmds.c
*** rcscmds.c 14 Feb 2001 04:31:27 - 1.50
--- rcscmds.c 19 Jun 2002 03:31:51 -
***
*** 245,254
--- 245,258
char *tmp1, *tmp2;
char *diffout = NULL;
int retval;
+ struct stat file_info;
if (options != NULL options[0] != '\0')
assert (options[0] == '-' options[1] == 'k');
+ if (CVS_STAT (workfile, file_info) 0)
+ error (1, errno, could not stat %s, workfile);
+
cvs_output (RCS file: , 0);
cvs_output (rcs-path, 0);
cvs_output (\n, 1);
***
*** 298,305
only for diagnostic messages -- CVS no longer forks to run diff3. */
diffout = cvs_temp_name();
call_diff_setup (diff3);
! call_diff_arg (-E);
! call_diff_arg (-am);
call_diff_arg (-L);
call_diff_arg (workfile);
--- 302,308
only for diagnostic messages -- CVS no longer forks to run diff3. */
diffout = cvs_temp_name();
call_diff_setup (diff3);
! call_diff_arg (-ATam);
call_diff_arg (-L);
call_diff_arg (workfile);
***
*** 321,326
--- 324,332
if (diffout)
copy_file (diffout, workfile);
+
+ if (chmod (workfile, file_info.st_mode) 0)
+ error (0, errno, cannot change mode of file %s, workfile);
/* Clean up. */
{
--
Greg A. Woods
+1 416 218-0098; [EMAIL PROTECTED]; [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
New feature/command
Hi I use CVS for all my source code development and document creation. My standard workstation is a Laptop which I connect to LANs and WANs. My repository is served via pserver. One feature I would really love is something like cvs chroot which I could run on my laptop to modify all the CVS/Root files, depending on which network I am on. That is my CVS/Root looks like :pserver:[EMAIL PROTECTED]:/home/user/repository and after cvs chroot :pserver:[EMAIL PROTECTED]:/home/user/repository the CVS/Root would look like :pserver:[EMAIL PROTECTED]:/home/user/repository and ALL the subsequent CVS commands route through correctly to my host. Currently, I manually go through all the CVS directories, changing the file by hand. I have a small script to do it, but it would be good to have it as part of CVS. The main reason for doing it this way rather than committing, deleting and checking out again is that some files are massive. Downloading them over a modem via my ISP would take too long. I down load the files from my local LAN and then hit the road and continue working/checking in files etc. Thanks Stu. -- - Stuart Midgley | [EMAIL PROTECTED] Supercomputer Facility | [EMAIL PROTECTED] Leonard Huxley Building 56 | +61 (0)2 6125 5988 Work Australian National University | +61 (0)2 6125 8199 Fax CANBERRA ACT 0200 | +61 (0)4 1125 2488 Mob ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: New feature/command
Stuart Midgley writes: I use CVS for all my source code development and document creation. My standard workstation is a Laptop which I connect to LANs and WANs. My repository is served via pserver. One feature I would really love is something like cvs chroot which I could run on my laptop to modify all the CVS/Root files, depending on which network I am on. You shouldn't need to change your CVS/Root files when you change networks. You just need to set up your DNS and/or network routing correctly. -Larry Jones Another casualty of applied metaphysics. -- Hobbes ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: New feature: Restricted admin command
[EMAIL PROTECTED] on 06/12/2000 12:27:09 AM It would be useful if you could also allow people to change a file to binary from ascii (Or vice versa). Ive found thats one of the most common requests of people and it needs *admin* capability. Oh yeah, I forgot about this one. Although this use of "cvs admin" makes everything much easier, in theory, it is not absolutely necessary (ie just "cvs rm file; cvs add -kb file"). Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates.
