Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Lenny Foner <[EMAIL PROTECTED]> writes:
> Date: Tue, 24 Oct 2000 14:46:13 -0400 (EDT)
> From: [EMAIL PROTECTED] (Larry Jones)
>
> Derek R. Price writes:
> >
> > I'm thinking maybe the standard test comes close to the argument length
> > limit and something about your system pushes it over the edge.
>
> On many systems, the environment counts against the maximum argument
> length limit; if you've got a lot of enviroment variables or some with
> very long definitions, try deleting them before running the tests. (You
> may find env -i [some versions use - instead of -i] to be a handy way to
> do that.)
>
> Ah ha! This is -exactly- what the problem was. I have somewhat over
> 300 environment variables (printenv returns about 11K bytes), since I
> often point at useful parts of the filesystem with them. (Do aliases
> count as well? What else? Why isn't this -documented- anywhere? Why
> in the world is it -true-? Even in GNU products? Unheard-of!)
>From the Unix98 standard:-
The number of bytes available for the new process' combined
argument and environment lists is {ARG_MAX}. It is
implementation-dependent whether null terminators, pointers,
and/or any alignment bytes are included in this total.
--
James Youngman
Manchester, UK. +44 161 226 7339
PGP (GPG) key ID for <[EMAIL PROTECTED]> is 64A95EE5 (F1B83152).
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Latest ".trunk" + ".origin" patch
For any who are interested, I've updated my ".trunk" + ".origin" patch vs. the current (nov 1, 2000) development version of CVS. http://www.geocities.com/dotslashstar/branch_patch.html Only change since last time is change to sanity.sh to account for recent fix to "cvs add" to handle "-Q" option. -- steve __ Do You Yahoo!? >From homework help to love advice, Yahoo! Experts has your answer. http://experts.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Unsubscribe me..
Any body know how I can unsubscribe from the list.. Had a nice time with u people.. Thanks.. Raghu K Software Engineer Pretzel Logic Sofware Inc. Cupertino, California email : [EMAIL PROTECTED] phone: 408-366-9010 extn 338 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Starting New Repository - Vendor Branch - Bug/Feature? (was: CVS IMPORT Help)
On Mon, Oct 30, 2000 at 10:12:31PM +, Spencer L. Swift wrote: > I am a fairly experienced CVS user, but only recently understood the > basic concept behind the Vendor Tag/Branch and the main trunk when you > first import an existing set of source files. In effect, the initial > Vendor Tag specifies a branch with revision number 1.1.1 containing > files all of revision 1.1.1.1. These are IDENTICAL to the initial > files (all at revision 1.1) on the main trunk. Correct. Not just "in effect", but in literal fact. To see this, look carefully at the output of "cvs log" for such a newly-imported file. > lonestar(11)$ cvs status -v wdrivn.f > === > File: wdrivn.f Status: Up-to-date > >Working revision:1.1.1.1 >Repository revision: 1.1.1.1 /Repository/Applications/Gent_Cane/src/wdrivn.f,v >Sticky Tag: (none) >Sticky Date: (none) >Sticky Options: (none) > >Existing Tags: > GentCane_v1 (revision: 1.1.1.1) > code970 (branch: 1.1.1) > > > Why does CVS report that my working revision is 1.1.1.1? Is that a > bug or a feature? Shouldn't it say 1.1? It's a feature; it should not say "1.1". Recall that a major use (arguably the main use) of "cvs import" is not to initially bring your existing project under CVS control, but to help you track third-party sources (eg. the CVS distribution itself, if you plan to hack the code) on an ongoing basis. You're using CVS 1.10. Suppose you've just done "cvs import"ed that; as you've noted, all the files are on the vendor branch, at rev. 1.1.1.1. Now you modify configure.in, since you had to do some work to port CVS to your version of IRIX :-) You commit the results. You write and commit the corresponding ChangeLog entry :-), so now (as you've noted) ChangeLog is at rev. 1.2, on the trunk. But IRIX portability fixes aren't NEWSworthy, so you leave the NEWS file alone; it's still at rev. 1.1.1.1 on the vendor branch. Actually, it took you a couple of tries to get the configure.in changes right, so now configure.in is at 1.3 on the trunk (ignore the bootstrapping problem of how you committed rev 1.2 of configure.in before you'd managed to get CVS to compile :-) Now consider what happens when you decide to upgrade to CVS 1.11 (which you should, by the way -- it's lots better!). You do a "cvs import" of the 1.11 distribution. Each of the files mentioned has changed between 1.10 and 1.11; the new version of each goes onto the vendor branch, as rev. 1.1.1.2. After you've merged your changes (using "cvs update" with a -j option or two) and committed the results, configure.in now looks like: Dflt: 1.1>1.2>1.3>1.4 \ * * * \** * \ * * * 1.1.1.1--->1.1.1.2 cvs_1_10 cvs_1_11 where the solid lines show actual predecessor-successor relationships, and the "*" lines show "influence" that (alas) is not reflected in the data structures; ie. 1.2 and 1.3 are "1.1.1.1 plus your changes", and 1.4 is "1.1.1.2 plus your changes". The diagram also shows the release tag(s) assigned by "cvs import" to each revision on the vendor branch. Because there are local changes, the latest-and-greatest revision is the latest one on the trunk, ie. 1.4. CVS keeps track of this by flagging the trunk as the default branch. I show this with "Dflt:" in the diagram. In practice, you can see it by looking at the "Branch:" entry in the output of "cvs log": if a file is "on the trunk", that entry will be blank. Since you didn't make any local changes to NEWS, it looks like this: 1.1 \ \ \ Dflt: 1.1.1.1--->1.1.1.2 cvs_1_10 cvs_1_11 The latest revision on the vendor branch (now 1.1.1.2) is still the latest-and-greatest; thus the vendor branch, 1.1.1, is flagged as the default branch. The GPL hasn't changed in years, so the file COPYING is even simpler. It hasn't changed between 1.10 and 1.11, and you didn't make any local changes(!). That file looks like: 1.1 \ \ \ Dflt: 1.1.1.1 cvs_1_10 cvs_1_11 CVS didn't create a new vendor-branch revision, since the file hasn't changed; it just added a cvs_1_11 release tag to the existing revision. This last is your situation (except that you only have one release tag so far). It should be clear by now that the behaviour which puzzles you makes perfect sense in general, and only looks odd in this degenerate case. It might be useful to think of the first import as looking like: Dflt: 1.1.1.1 cvs_1_10 Then again, maybe that's more confusing. Either way, you should just ignore rev. 1.1 completely, as CVS tries its best to do. It's only there because the underlying data structure (which, recall, was borrowed from RCS, not inv
committing linked files
I have a problem that I was trying to solve by checking in linked files (ln -s) and wanted to know if anyone else knew of a better solution. Problem: I am working for a company that currently has a library of designs under CVS control. The next step is to use these designs in a project also under CVS control, but deposited in a separate repository. Currently I have created a common checkout directory to reference these designs by linking the appropriate files into the new projects working directory to ensure that the correct release is referenced. However, when I go to commit the linked files, the link is broken when the file is checked back out. I have considered creating another commit option to not perform the checkout, which will probably work, but I was wondering if there is a better way. Any feedback would be greatly appreciated. Andy Probst TDK Semiconductor Nevada City, CA ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Syncing New Working Directories with an Old cvs Repository
Alexy Khrabrov wrote: > I have an interesting reverse-update case: my working copies are OK, but > the partition where the CVS repository is kept was formatted over by a > buggy Red Hat 7.0 anakonda installer (fixed a day later:-). Please check the email archives. I have answered this question at least twice before and the answer is rather long. I believe the subject line of the last thread was something like "restoring repository from backup" Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "Let me tell you the most beautiful story I know. A man was given a dog, which he loved very much. The dog went with him everywhere, but the man could not teach it to do anything useful. The dog would not fetch or point, it would not race or protect or stand watch. Instead the dog sat near him and regarded him, always with the same inscrutable expression. 'That's not a dog, that's a wolf,' said the man's wife. 'He alone is faithful to me,' said the man, and his wife never discussed it with him again. One day the man took the dog with him into his private airplane and as they flew high over winter mountains, the engines failed and the airplane was torn to shreds among the trees. The man lay bleeding, his belly torn open by blades of sheared metal, steam rising from his organs in the cold air, but all he could think of was his faithful dog. Was he alive? Was he hurt? Imagine his relief when the dog came padding up and regarded him with that same steady gaze. After an hour the dog nosed the man's gaping abdomen, then began pulling out intestines and spleen and liver and gnawing on them, all the while studying the man's face. 'Thank God,' said the man. 'At least one of us will not starve.'" -Orson Scott Card, "Children of the Mind" ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Resolving conflict.
En réponse à Dave Sherohman <[EMAIL PROTECTED]>: > On Fri, Oct 27, 2000 at 11:45:41PM -, Fabrice Gautier wrote: > > How do I told cvs that these are resolved ? > > > > (cvs bible say commit, but i can't I'm read-only) > > You just answered your own question: You can't resolve the conflict > because > you're read-only. No, the fact is I can. (Otherwise, this would be a bug not a feature) I had forgotten a conflict marker in the source, once removed its status was M (Modified) not C (Conflict) Regards, -- Fabrice Gautier [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: access rights to branches
On Wednesday, November 01, 2000 1:43 AM, Laird Nelson [SMTP:[EMAIL PROTECTED]] wrote: > Shem Mazur wrote: > > I have a CVS user who continues to checkout modules or update files from > > the wrong branches. Can I restrict her ability to update from > > particular branches or main trunk? > > What the various other replies were trying (somewhat unhelpfully :-)) to > tell you is no, not with CVS out of the box. With its commitinfo > mechanism you can't get access to either (a) the new revision number > prior to the commit taking place (a feature that sure would be nice to > have) or (b) whether or not the user supplied a -r switch to the commit > command. If you could get either (a) or (b) then you could reliably > block commits onto a branch. > There was a patch posted to this group a while ago, to add revision information to the rest of the information passed to commitinfo. Check out the following at cvshome.org for more details: http://www.cvshome.org/cyclic/cvs/dev-commitinfo.txt http://www.cvshome.org/dev/patches/commitinfo These both seem to be pointers to the same patch, but I haven't confirmed this. This patch will require changes to all your commitinfo scripts. *** Chris CameronOpen Telecommunications NZ Ltd Senior Solution Architect IN Product Management [EMAIL PROTECTED] P.O.Box 10-388 +64 4 495 8403 (DDI) The Terrace fax: +64 4 495 8419 Wellington cell: +64 21 650 680New Zealand Life, don't talk to me about life (Marvin - HHGTTG) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Finding Binary Files
Jon Wilson wrote:
> If you don't have or don't want Perl (why? :-0) then you could probably
> monkey up a shell script using the Unix 'file' command. Have a look at
> 'man file' to see exactly how your local version works, but you should be
> able to easily tell whether a file is one of 'text', 'executable' or
> 'data'.
In testing on a Sun Solaris 2.6 machine, I'd found that if the contents of the Unix
file command returns "text" or "script" as part of the return value, it is
*probably* an ASCII file; otherwise it is *probably* a binary file. Your mileage
may vary!
e.g. check it from a perl script with the filename contained in $arg
$result = `/usr/bin/file $arg`;
if (( $result =~ /:.*text/ ) ||
( $result =~ /:.*script/ ) ) {
# This is *probably* an ASCII file
}else
{
# This is *probably* a binary file
}
David
begin:vcard
n:Martin;David
tel;work:(469) 524-6490
x-mozilla-html:FALSE
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
end:vcard
Re: Finding Binary Files
If you don't have or don't want Perl (why? :-0) then you could probably monkey up a shell script using the Unix 'file' command. Have a look at 'man file' to see exactly how your local version works, but you should be able to easily tell whether a file is one of 'text', 'executable' or 'data'. On Tue, 31 Oct 2000, Derek R. Price wrote: > If you have Perl installed, you could use its binary file test operator which > will return true if the first block of the file contains >30% "special" > characters: > > perl -e 'exit(!(-f file && -B $ARGV[0]))' > > will return a Bourne shell true value if the file exists and is binary. So > in Bourne form: > > #!/bin/sh > for file in "$@"; do > if perl -e 'exit(!(-f file && -B $ARGV[0]))' "$file"; then > # do what I do to binary files > fi > done -- Jon Wilson [EMAIL PROTECTED] Dept. of Mathematical Sciences http://www.bath.ac.uk/~mapjpw University of Bath, UKTel. (07776) 137939 "Beware of all enterprises that require new clothes." - Thoreau ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: access rights to branches
"Derek R. Price" wrote: > > Laird Nelson wrote: > > > That said, if you know that your user will never try to force a commit > > using the -r switch (don't know how you'd know this, but most users > > don't use this flag), then you can write a commitinfo script that will > > check the old revision number and reject access based on it, making the > > assumption that the new revision number will be the old one with the > > rightmost number incremented by one. You could also check the tag. > > This isn't strictly true. The first commit of a file to a branch could go > from 1.X to 1.X.Y.1. Quite right, and, I might add, there's no workaround. :-( Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: access rights to branches
Andrew Gilmartin wrote: > What would be useful to us is a pre-commit check that made sure the user can > revise a given file and given branch or mainline. For example, > > # user file development-line > * #none #none > * com/mesasys/productA/* release_4_branch > asdcom/mesasys/productA/file1 > patch_1_branch,patch_2_branch,patch_3_branch > bnmcom/mesasys/productA/file1 #mainline,patch_*_branch > cvbcom/mesasys/productA/* #all > > This configuration would give 'asd' access to file1 only for patching, 'bnm' > access to file1 for patching and mainline development, and 'cvb' all access > to all files in all directories on all development lines for productA. > Otherwise all developers can commit changes to release 4 of productA and no > developers can commit other changes elsewhere. Right, or see http://cvssupport.sourceforge.net/cvsacl.dtd for an XML DTD that defines another syntax. Maybe I'll look into adding the above syntax as well. > I don't think this can be done currently as the commitinfo handlers you do > not have information about the line of development -- branch or mainline or > revision numbers. If you did then implementing this kind of access would be > straight forward and I think quite valuable. Perhaps we need a commitinfo2 > that provides this kind of information on the command line to the commit > handler. Again, if you can live with the assumption that the -r switch will never be used in conjunction with the cvs commit command, then you *can* implement this stuff (but it can always be overridden with the -r switch). The information is there, it's just in horrid locations and ad hoc bits. My cvssupport project (a) normalizes all the available information into a set of perl classes and (b) provides a flexible ACL plugin that allows you to do the above. See http://sourceforge.net/projects/cvssupport/ for details. A full announcement will follow when this project is ready for prime time; in the meantime of course you can look at the sources via SourceForge's cvs access mechanisms. Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Finding Binary Files
Manish Koolwal wrote: > From among a group of files, how can we find out which are Binary files? > (This is in reference to UNIX). Also, please help me if you know any fast > method to sagregate Binary Files. UNIX itself rarely makes a distinction. Some applications (like diff) make guesses based on the presence/proportion of NUL bytes & other special characters. If you have Perl installed, you could use its binary file test operator which will return true if the first block of the file contains >30% "special" characters: perl -e 'exit(!(-f file && -B $ARGV[0]))' will return a Bourne shell true value if the file exists and is binary. So in Bourne form: #!/bin/sh for file in "$@"; do if perl -e 'exit(!(-f file && -B $ARGV[0]))' "$file"; then # do what I do to binary files fi done Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I used to think people were crazy to get tattoos. Nowadays, I envy them that clarity of thought. There was at least one point in their lives when they thought they knew what they were doing. They could walk into a tattoo parlor and say, "I want a big old pig, in red and black, with flames shooting out of its rear! And I want it right there! That's who I am!" ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: access rights to branches
> Can I restrict her ability to update from > particular branches or main trunk? We have a similar issue in that we need to restrict who can update which files on the mainline and (sometimes branches). There was some discussion of this recently and the general approach taken was to implement a process that either passes checkins to a single group or have two copies of your CVS tree -- build and development -- and migrate revisions from development to build as authorized. In a large organization with many parallel development tracks both of these options are not suitable. What would be useful to us is a pre-commit check that made sure the user can revise a given file and given branch or mainline. For example, # user file development-line * #none #none * com/mesasys/productA/* release_4_branch asdcom/mesasys/productA/file1 patch_1_branch,patch_2_branch,patch_3_branch bnmcom/mesasys/productA/file1 #mainline,patch_*_branch cvbcom/mesasys/productA/* #all This configuration would give 'asd' access to file1 only for patching, 'bnm' access to file1 for patching and mainline development, and 'cvb' all access to all files in all directories on all development lines for productA. Otherwise all developers can commit changes to release 4 of productA and no developers can commit other changes elsewhere. I don't think this can be done currently as the commitinfo handlers you do not have information about the line of development -- branch or mainline or revision numbers. If you did then implementing this kind of access would be straight forward and I think quite valuable. Perhaps we need a commitinfo2 that provides this kind of information on the command line to the commit handler. -- Andrew ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: access rights to branches
Laird Nelson wrote: > That said, if you know that your user will never try to force a commit > using the -r switch (don't know how you'd know this, but most users > don't use this flag), then you can write a commitinfo script that will > check the old revision number and reject access based on it, making the > assumption that the new revision number will be the old one with the > rightmost number incremented by one. You could also check the tag. This isn't strictly true. The first commit of a file to a branch could go from 1.X to 1.X.Y.1. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) Cynic: Someone who smells the flowers and looks for the casket ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: locked files
[EMAIL PROTECTED] on 2000.10.30 13:21:30 >> This topic has been discussed numerous times and I still haven't seen an >> absolute need to use "cvs admin -l". > >Well, some people don't trust that if someone gets a conflict when >trying to merge, that the resulting file will be OK, because of human >errors. Whether a human does a manual merge (which is even more error-prone than automating the merge), developers should always double-check the result of the merge, anyway. Moreover, regression testing will catch semantic conflicts that no merge tool can detect and humans will often miss. >Locking stalls development, but encourages that one person does some right >without disturbance from others. "cvs edit -c" encourages communication (in which case, developers may decide to work serially) and allows concurrent development -- the best of both worlds. 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. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: access rights to branches
I know this won't address the problem directly. Anyway, create a commitinfo
script that'll prevent her from checking her stuff into the wrong branch.
Recovery from checking out or updating from the wrong branch should be fairly
straightforward ("cvs up -A").
Noel
[EMAIL PROTECTED] on 2000.10.30 20:41:29
To: [EMAIL PROTECTED]
cc: (bcc: Noel L Yap)
Subject: Re: access rights to branches
* $ from [EMAIL PROTECTED] at "31-Oct:12:31pm" | sed "1,$s/^/* /"
*
*
* Hi,
*
* I have a CVS user who continues to checkout modules or update files from
* the wrong branches. Can I restrict her ability to update from
* particular branches or main trunk? The only thing I can find about
* access rights with CVS is to do with Unix file permission this is
* fine if you want to stop someone from accessing a project, but not
* enough if you just want to restrict access to a particular branch in the
* project.
*
* Any help much appreciated (she's driving me nuts!!! ;)
Create a .cvsrc file in her home directory with branch tags for update/checkout
?
*
* Shem
*
richard.
---
Richard Offer Widget FAQ --> http://reality.sgi.com/widgetFAQ/
{X,Motif,Trust} on {Irix,Linux}
__http://reality.sgi.com/offer/
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
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.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: access rights to branches
Shem Mazur wrote: > I have a CVS user who continues to checkout modules or update files from > the wrong branches. Can I restrict her ability to update from > particular branches or main trunk? What the various other replies were trying (somewhat unhelpfully :-)) to tell you is no, not with CVS out of the box. With its commitinfo mechanism you can't get access to either (a) the new revision number prior to the commit taking place (a feature that sure would be nice to have) or (b) whether or not the user supplied a -r switch to the commit command. If you could get either (a) or (b) then you could reliably block commits onto a branch. That said, if you know that your user will never try to force a commit using the -r switch (don't know how you'd know this, but most users don't use this flag), then you can write a commitinfo script that will check the old revision number and reject access based on it, making the assumption that the new revision number will be the old one with the rightmost number incremented by one. You could also check the tag. I've got a project going that lets you do this with an XML file declaring who can do what. Branch commits (with the assumption made above) can be blocked based on any combination of filename pattern, revision pattern and/or tag pattern. Look at the cvs archives at http://sourceforge.net/projects/cvssupport/. Hope that helps, Cheers, Laird -- W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED] http://www.amherst.edu/~ljnelson/ Good, cheap, fast: pick two. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Finding Binary Files
Hi, From among a group of files, how can we find out which are Binary files? (This is in reference to UNIX). Also, please help me if you know any fast method to sagregate Binary Files. Thanks and Regards, Manish Koolwal _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Feature request for cvs log command
I would like to request a feature enhancement to the cvs log command. With the cvs log command, you can do stuff like "cvs log -d > '1 Jan 2000 12:34:56' " and get all the revision history after 1 Jan 2000 @ 12:34:56. My request is to be able to do the same with the -r option, thus "cvs log -r>rel-1-0" would produce a log, selecting revisions that have been made *after* the code was tagged with release 1.0. This goes back to a question I asked a while ago about displaying revision history *after* a particular tag so that I could produce a change log file. Currently the -r option *includes* the requested tag, so it includes some changes that were in a previous release. At present the only way I can see to do this is to look at the date of the tag and then look at revisions made after that date. A slicker way would be to do this directly from the tag. Any comments? Regards John. Click here to visit the Argos home page http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and confidential, and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution, dissemination or use of this communication is not authorised. If you have received this message in error, please advise the sender by using the reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for virus, high risk file extensions, and inappropriate content. As a result users should be aware that mail may be accessed. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Format of the input to the command specified in "loginfo"
Hi, Is there some document that describes the format of the input given to the commands specified in the "loginfo" file? Thanks, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
