unsubscribe

[Dipl.Ing. Marius Oancea]

 

begin:vcard 
n:Oancea;Marius
x-mozilla-html:FALSE
org:SOFTWARE Engeneering;"It said uses Windows NT or better, so I loaded Linux !"
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;-6656
fn:Marius Oancea
end:vcard

latest patches posted to SourceForge RCVS

[Noel L Yap]

OK, I've posted my latest (iterative) patches.  These cover:
1. fixes to "cvs edit" and "cvs unedit"
2. non-interactive "cvs release"
3. proper file chmod'ing by "cvs unedit" and "cvs update"
4. logging of client username instead of server username

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.

Repeatedly merging from branch to trunk

[Brian Collins]

I thought I had this strainght but apparently not so if someone can help me
figure it out I'd appreciate it!  We're using release 1.10 (Halibut)

We have (or are planning to have) a branch to hold patches to a release (for
this example, branch tag = patches).  As patches are committed to the branch, we
want to merge them back to the trunk in order to keep the trunk up to date.  So
that we don't get conflicts each time we do this, we have a tag on the branch
(patches_last_merge) which we move after each merge.  This works fine until we
want to do the fix differently on the trunk as opposed to the branch.  

eg. on the branch, the file f1 contains:
  Line 1
  Line 2 on the branch

and on the trunk it contains:
  Line 1
  Line 2 on the trunk

Now, we move the tag on the branch so that it's pointing to the latest revision
on the branch:
  cvs tag -F -r patches patches_last_merge f1

Just to see what happens:
  cvs update -A
  cvs update -j patches_last_merge -j patches f1
As expected, f1 doesn't change because the tag is on the head of the branch

So, back to the branch, add another line (Line 3), commit it and merge it back
to the trunk as above.  This gives conflicts, thus:
  Line 1
  <<< f1
  Line 2 on the trunk
  ===
  Line 2 on the branch
  Line 3
  >>> 1.1.2.2

when all I expected was the automatic merging of "Line 3"!

  cvs diff -r patches_last_merge -r patches f1

gives the expected output:
  diff -b -c -r1.1.2.1 -r1.1.2.2
  *** f1  2000/06/20 00:40:32 1.1.2.1
  --- f1  2000/06/20 00:55:48 1.1.2.2
  ***
  *** 1,2 
  --- 1,3 
Line 1
Line 2 on the branch
  + Line 3

and I thought that all the merge was doing was taking a diff between
patches_last_merge and patches and applying it to the working copy.  What am I
missing here?

Lastly, if I resolve the conflicts, move the tag, then make a further change on
the patches branch, the subsequent merge to the trunk works as expected.

Yours in confusion,

--

"Everyone is ignorant, only on different subjects." (Will Rogers) 

Brian Collins
Triple G Asia Pacific
http://www.tripleg.com

Re: ".trunk" patch refinement

[Eric Siegerman]

I'm well aware that bumping trunk revisions to 2.x or greater is
pretty useless, and that tags are the right way to go, especially
since after you do it, newly-added files will still get 1.x
revisions.  However...

On Mon, Jun 19, 2000 at 05:01:45PM -0400, Greg A. Woods wrote:
> However people should *not* ever be doing such silly things -- there are
> more corner cases than just this one whre they can get into trouble!

... I wasn't aware that it's actively dangerous, as Greg seems to
be saying.  If so, is there any reason to keep it?  Why not just
make commit's -r option go away?

> [ On Monday, June 19, 2000 at 17:12:42 (+0100), Mike Little wrote: ]
> > Would '-r1' work if some previous cvs admin had updated vast numbers of the 
> > trunk revisions to 3.x (presumably when version 3.0 of the product was
> > released)?

"say -r1 when you mean latest-on-trunk" is a kludge, to work
around the lack of ".trunk".  That it fails on trunk revision 2.x
isn't a corner case in CVS; it's a limitation of the kludge.

The man's offering to obviate this kludge with a correct
solution; what's all the grumbling about?

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
[Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD 
- Netcraft's "What's that site running?" service, 12-Jun-2000

Re: ".trunk" patch refinement

[Russ Allbery]

David Thornley <[EMAIL PROTECTED]> writes:

> Either way, any technique that assumes that all main trunk development
> is on rev numbers 1.* is useless to me, and probably to quite a few
> people.

And it's quite possible to get into that state without any misuse of CVS
at any point.  It's worth remembering that a lot of us are using CVS
repositories formed from imported RCS files, and using different rev
numbers with RCS is extremely common.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: ".trunk" patch refinement

[Greg A. Woods]

[ On Monday, June 19, 2000 at 17:13:10 (-0500), David Thornley wrote: ]
> Subject: Re: ".trunk" patch refinement
>
> Since it's a very natural thing to do, lots of people have done
> it.  It's easy (and correct) to say they should not have done
> that, but the important fact is that it has been done.

However the important thing now is to continue to deprecate that
practice.  That includes removing the instructions for doing it from the
manual (and replacing them with dire warnings against doing it), and
most definitely not adding new code that's expressly designed to handle
only one of the corner cases that this sillyness introduces.

(If someone found some way to clean up *all* of the corner cases, and if
they could justify the effort this would take even in the face of the
design goal of using symbolic tags to identify such things, then that
might be a somewhat different matter)

> Mike Little referred to "some previous cvs admin", and this is
> precisely what happened in my case.  Some previous CVS admin
> put some of the rev numbers to 2.x, and there's no way I can put
> them back to 1.x.  This has doubtless happened to many admins;
> either they inherited such a repository, or they created the problem
> themselves while not knowing better.

It may be possible to renumber the trunk back to "normal", especially if
there aren't too many branches in your repository

> Either way, any technique that assumes that all main trunk development
> is on rev numbers 1.* is useless to me, and probably to quite a few
> people.

You can also leap-frog into a new repository starting fresh with "1.1"
at some major milestone in your project.  The actual amounts of use of
history information is usually far lower than people surmise without
measurements and indeed is extremely low if you only examine events
where users back past a major milestone.  You don't have to 100% cut
them off from the old history either -- just keep it in a read-only
repository for easy local access and then occasionally audit to see how
often it's accessed before you retire it for good.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]>  
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

cvs export as root

[Hamid Ghassemi]

I am trying to do a CVS EXPORT as root and I get the following error;

telly# cvs export -r HEAD filesys
cvs [export aborted]: cannot write : No such file or director

We are using pserver to access CVS.  This problem does not exist if I acces cvs in 
local mode.

Any ideas?

Re: [ANN] WinCvs 1.1b14 is out

[Mark Derricutt]

On Mon, 19 Jun 2000, Alexandre Parenteau wrote:

> http://devnet.3d.com/cvsweb/cvsweb.cgi/cvsgui/ChangeLog
> http://www.wincvs.org/download.html

Whilst not actually on the webpage yet, the file is there at
http://www.wincvs.org/WinCvs11b14.zip

Mark

-- 
Inspired by the taste of horror, proud to be insane forever
Let out the killer in me! (c) Dismal Euphony
Now Playing: 

RE: ".trunk" patch refinement

[Stephen Rasku]

>
>>> -Original Message-
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>>>
>>> [...] OK, so exactly how is this different from "-r1"?
>>>
>>
>>Would '-r1' work if some previous cvs admin had updated vast numbers 
of the
>>trunk revisions to 3.x (presumably when version 3.0 of the product 
was
>>released)?
>>
>
>I would just like to point out that trying to use CVS revision
>numbers as module or system version numbers is a bad, bad thing
>to do.  This cannot be reiterated enough, and I realize that you
>did not suggest doing it Mike, but some people might get the
>mistaken impression that this use of revision numbers is not
>the mistake that it is.
>

What I don't understand is:  If something is bad, why is it allowed.  
If using this feature is dangerous, then it should be removed from 
CVS.

-- 
Stephen Rasku   E-mail: [EMAIL PROTECTED]
Senior Software EngineerPhone:  (604) 872-6676
TGI TechnologiesWeb:http://www.tgivan.com/

RE: ".trunk" patch refinement

[Cameron, Steve]

Greg Woods wrote:
> [ On Monday, June 19, 2000 at 17:12:42 (+0100), Mike Little wrote: ]
> > Subject: RE: ".trunk" patch refinement
> >
> > Would '-r1' work if some previous cvs admin had updated vast numbers of
> the 
> > trunk revisions to 3.x (presumably when version 3.0 of the product was
> > released)?
> 
> I don't know for sure -- I never tried it.
> 
> However people should *not* ever be doing such silly things -- there are
> more corner cases than just this one whre they can get into trouble!
> 
> (Yes, the manual gives instructions on how to do this -- it should not.)
[smc]  Other than perhaps to say, "don't do that."

However, just because you shouldn't doesn't mean 
nobody will, if only out of ignorance, or by a typing 
accident, and pretty much anyone with commit 
access may do this, and once it's done, then what?  
Manually edit the RCS files to fix it?  Abandon the
repository in frustration and refuse to work with such
idiots?  This latter is more or less what you propose 
CVS should (continue to) do ;-) at least in the area of
having a way to refer to the trunk other than a fresh
checkout.

There are at least a couple ways this can happen, one 
is "cvs commit -r" and another is copying in RCS files from
someplace else.  (The latter is the world I come from, so
I've got lots of RCS files with weird revision numbers.)

Sure, you may certainly say, "sorry, too bad, go away", 
but that's not what _I'm_ going to say.  I will however concede
that this ".trunk" feature is for me only a "nice-to-have" and
not a "need-to-have", I've lived without it for 3 years now,
and others have dealt with its absence for considerably
longer than that.

And as it happens our current development process 
involves committing to the trunk only rarely, when a branch 
is merged to the trunk.  It's just something that's always
bugged me that HEAD was so weirdly implemented 
and this "-r1" isn't obvious to anyone and only works by 
a quirk of RCS and then only under a limited set of 
circumstances, and when it doesn't work, it doesn't
TELL you that it's not working so you easily might
fail to notice that you'd generated the wrong diffs or 
whatever.  (or the other probably more correct 
interpretation, -r1 works perfectly, if that's not 
what you wanted, well, sorry..)

I would be interested in knowing about any other
"corner cases" I might run into with my mal-formed
repository that you might be aware of. 

-- steve

Re: ".trunk" patch refinement

[David Thornley]

[EMAIL PROTECTED] wrote:
> 
> 
> I would just like to point out that trying to use CVS revision
> numbers as module or system version numbers is a bad, bad thing
> to do.  This cannot be reiterated enough, and I realize that you
> did not suggest doing it Mike, but some people might get the
> mistaken impression that this use of revision numbers is not
> the mistake that it is.
> 
> Rex.

Right.

It's unfortunate that CVS supports the reassignment of revision
numbers.  It's a very natural thing to do to move all the rev
numbers up to 2.1 for release 2, rather than creating a tag,
which is of course the correct thing to do.

Since it's a very natural thing to do, lots of people have done
it.  It's easy (and correct) to say they should not have done
that, but the important fact is that it has been done.

Mike Little referred to "some previous cvs admin", and this is
precisely what happened in my case.  Some previous CVS admin
put some of the rev numbers to 2.x, and there's no way I can put
them back to 1.x.  This has doubtless happened to many admins;
either they inherited such a repository, or they created the problem
themselves while not knowing better.

Either way, any technique that assumes that all main trunk development
is on rev numbers 1.* is useless to me, and probably to quite a few
people.

-- 
David H. Thornley  Software Engineer
at CES International, Inc.:  [EMAIL PROTECTED] or (763)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/

RE: ".trunk" patch refinement

[Greg A. Woods]

[ On Monday, June 19, 2000 at 17:12:42 (+0100), Mike Little wrote: ]
> Subject: RE: ".trunk" patch refinement
>
> Would '-r1' work if some previous cvs admin had updated vast numbers of the 
> trunk revisions to 3.x (presumably when version 3.0 of the product was
> released)?

I don't know for sure -- I never tried it.

However people should *not* ever be doing such silly things -- there are
more corner cases than just this one whre they can get into trouble!

(Yes, the manual gives instructions on how to do this -- it should not.)

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]>  
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

RE: ".trunk" patch refinement

[Rex_Jolliff]

Mike Little <[EMAIL PROTECTED]> on 06/19/2000 09:12:42 AM

To:   "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, "'[EMAIL PROTECTED]'"
  <[EMAIL PROTECTED]>
cc:(bcc: Rex Jolliff/YM/RWDOE)

Subject:  RE: ".trunk" patch refinement




>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>>
>> [...] OK, so exactly how is this different from "-r1"?
>>
>
>Would '-r1' work if some previous cvs admin had updated vast numbers of the
>trunk revisions to 3.x (presumably when version 3.0 of the product was
>released)?
>

I would just like to point out that trying to use CVS revision
numbers as module or system version numbers is a bad, bad thing
to do.  This cannot be reiterated enough, and I realize that you
did not suggest doing it Mike, but some people might get the
mistaken impression that this use of revision numbers is not
the mistake that it is.

Rex.

[ANN] WinCvs 1.1b14 is out

[Alexandre Parenteau]

http://devnet.3d.com/cvsweb/cvsweb.cgi/cvsgui/ChangeLog
http://www.wincvs.org/download.html

RE: ".trunk" patch refinement

[Mike Little]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 19, 2000 3:48 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: ".trunk" patch refinement
> 
> [ On Saturday, June 17, 2000 at 21:41:49 (-0700), Stephen 
> Cameron wrote: ]
> > Subject: ".trunk" patch refinement
> >
> > Ok, here's a refinement of my ".trunk' patch that gives
> > the trunk a branch-tag name, just like other branches
> > (from the user's perspective, the implementation is rather
> > different.)
> 
> OK, so exactly how is this different from "-r1"?  Seems like it's the
> same thing to me, which means it's an awful waste of coding 
> effort, not
> to mention the extra typing necessary to use it...  ;-)
> 

Would '-r1' work if some previous cvs admin had updated vast numbers of the 
trunk revisions to 3.x (presumably when version 3.0 of the product was
released)?

Mike

--
Mike Little
Share what you know. Learn what you don't.

ServicePOWER Business Solutions Ltd
home: [EMAIL PROTECTED]
 

RE: ".trunk" patch refinement

[Cameron, Steve]

I wrote:
> Greg Woods wrote:
 [...] 
>   OK, so exactly how is this  [my .trunk patch] different from "-r1"?
> Seems like it's the
>   same thing to me, which means it's an awful waste of coding effort,
> not
>   to mention the extra typing necessary to use it...  ;-)
>   [smc]  
> 
>   ".trunk" has the possibility of handling the case where
>   sombody has done "cvs commit -r2 foo",   (though I haven't
>   tested that case.)
> 
[smc]  I just tried it.

echo x > x
cvs add x
cvs commit -m x x
cvs tag one x
echo 2 >> x
cvs commit -r 2.1 -m x x
cvs diff -r one -r1 x
(no output, that is, the diffs between rev 1.1 and rev 1.1 )
cvs diff -r one -r.trunk x
(you get the diffs between rev 1.1 and rev 2.1)

I'll be adding such a case to sanity.sh in my patch later.

(Does this justify the effort?  who am I to say?)

-- steve

Re: can't "./configure"

[Larry Jones]

Chris Carbaugh writes:
> 
> I've downloaded the source via that 'nifty' (yea right) java
> app cyclic has up now.

That ``nifty'' Java app doesn't seem to work at all for me.  If you
continue to have problems, you might want to try going to the CVS
download site (ftp://ftp.cvshome.org/pub/) and downloading the
traditional gzipped tar file.

-Larry Jones

Even if lives DID hang in the balance, it would depend on whose they were.
-- Calvin

RE: ".trunk" patch refinement

[Cameron, Steve]

Greg Woods wrote:
> [ On Saturday, June 17, 2000 at 21:41:49 (-0700), Stephen Cameron wrote: ]
> > Subject: ".trunk" patch refinement
> >
> > Ok, here's a refinement of my ".trunk' patch that gives
> > the trunk a branch-tag name, just like other branches
> > (from the user's perspective, the implementation is rather
> > different.)
> 
> OK, so exactly how is this different from "-r1"?  Seems like it's the
> same thing to me, which means it's an awful waste of coding effort, not
> to mention the extra typing necessary to use it...  ;-)
[smc]  

".trunk" has the possibility of handling the case where
sombody has done "cvs commit -r2 foo", (though I haven't
tested that case.)

We've had this conversation before, actually, here's part
of what we wrote:, (thanks deja.com)
> Greg Woods wrote:
> [...: ]
> > It makes me wonder though if a magic pseudo-tag could even be
> > implemented right in the case of bumped release numbers without
jumping
> > through a whole lot of hoops.  I can't at the moment think of a
way to
> > inidicate to RCS that the top of the trunk should be always used
without
> > getting the "default branch" stuff involved and messing with
that
> > doesn't work well with CVS either since it's effectively
reserved for
> > internal use only.
> [smc]  Yeah I think implementing what I want would 
> be pretty hard...  But, the changes might be at least 
> localized to the RCS code, excepting any changes 
> needed to handle a  tag name that begins with a dot, 
> (i.e. ".trunk" or something as mentioned in the docs.  

And then I went on to explain that I was "bullheaded
enough" to want ".trunk" even though I didn't _need_ it. :-)

-- steve

Re: ".trunk" patch refinement

[Greg A. Woods]

[ On Saturday, June 17, 2000 at 21:41:49 (-0700), Stephen Cameron wrote: ]
> Subject: ".trunk" patch refinement
>
> Ok, here's a refinement of my ".trunk' patch that gives
> the trunk a branch-tag name, just like other branches
> (from the user's perspective, the implementation is rather
> different.)

OK, so exactly how is this different from "-r1"?  Seems like it's the
same thing to me, which means it's an awful waste of coding effort, not
to mention the extra typing necessary to use it...  ;-)

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]>  
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

Subscribe

[Gordon Stone]

Please re subscribe me to the list.

Gordon Stone
Technical Author, Senior A/P
World Online UK
www.worldonline.co.uk
Tel. +44 (0)870 748 4436


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 12 April 2000 13:56
> To: [EMAIL PROTECTED]
> Subject: Re: Unsubscribe
>
>
> 32746 [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> You have been removed from the list.
>
> If this wasn't your intention or you are having problems getting yourself
> unsubscribed, reply to this mail now (quoting it entirely (for diagnostic
> purposes), and of course adding any comments you see fit).
>
> Transcript of unsubscription request follows:
> --
> >From [EMAIL PROTECTED]  Wed Apr 12 08:55:52 2000
> >Received: from telinco.net (internal.mail.telinco.net [212.1.128.4])
> > by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id IAA27614
> > for <[EMAIL PROTECTED]>; Wed, 12 Apr 2000 08:55:50 -0400
> >Received: from pilchards.telinco.net ([212.1.128.253] helo=DTUKNGORDONST)
> > by telinco.net with smtp (Exim 3.02 #1)
> > id 12fMgI-000D0G-00
> > for [EMAIL PROTECTED]; Wed, 12 Apr 2000 13:55:42 +0100
> >From: "Gordon Stone" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Subject: Unsubscribe
> >Date: Wed, 12 Apr 2000 13:49:56 +0100
> >Message-ID: <[EMAIL PROTECTED]>
> >MIME-Version: 1.0
> >Content-Type: text/plain;
> > charset="iso-8859-1"
> >Content-Transfer-Encoding: 7bit
> >X-Priority: 3 (Normal)
> >X-MSMail-Priority: Normal
> >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
> >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> >Importance: Normal
> >
> >
> > I hope this is the correct way to unsubscribe (only temporary
> over Easter
> >period)
> >
>
>
>

ANNOUNCE: CVS Manual Translation Project Release 0.3.4

[Karl Heinz Marbaise]

Begin3
Title:  CVSMTP
Version:0.3.4
Entered-date:   19Jun00
Description:CVS Manual Translation Project (CVSMTP)
Project to translate the CVS documentation
into german and other languages.
Coordination should be done by e-mailing
to the author.
A mailing list does exist for further
details take a look on the web-site.
Keywords:   documentation CVS german italian frensh portuguese
Author: [EMAIL PROTECTED] (Karl Heinz Marbaise)
[EMAIL PROTECTED] (Carsten Frewert)
[EMAIL PROTECTED] (Malimpensa Stefano)
[EMAIL PROTECTED] (Mark Soiseth)
[EMAIL PROTECTED] (Thomas Tschoepke Soares)
Maintained-by:  [EMAIL PROTECTED] (Karl Heinz Marbaise)
Primary-site:   http://www.fido.de/~kama/cvsmtp/cvsmtp.html
720kB ftp://ftp.fido.de/pub/cvs/cvsmtp-0.3.4.tar.gz
170kB ftp://ftp.fido.de/pub/cvs/cvsmtp-src-0.3.4.tar.gz
Alternate-site:
Original-site:
Platforms:
Copying-policy: GPL Version 2.0 or later (see CVS manual)
End


--
Jabba dabba dooohhh  e-mail: [EMAIL PROTECTED]
'til next mail.Internet: http://www.fido.de/~kama
  Karl Heinz 7:-)   Fidonet: 2:2452/110.18
  Voice: +49 241 962380

Re: Files created on Branch

[Shane Turner]

We are using 1.10.8 in local mode and via rsh.

Shane

Eric Siegerman wrote:

> Which version of CVS?  I just tried this using 1.10.8 and it
> worked fine.

Re: ".trunk" patch refinement

[Stephen Cameron]

Well, I see one problem with my patch already:

--- Stephen Cameron <[EMAIL PROTECTED]> wrote:

This part, from cvs.texinfo:
+ 
+ CAUTION: the special tag `HEAD' is interpreted by
+ the `cvs diff' command in a different way than it
+ is interpreted by any other cvs command.  `cvs diff'
+ takes `-r HEAD' to mean the following, as nearly as
+ I can tell:
+ 
+ For `cvs diff', `HEAD' means the most recent revision
+ on the `current branch' (taking into account whatever
+ sticky tags are active in your working directory) unless
+ the particular file being diffed is not present on the
+ branch, in which case the head revision of the trunk is
+ taken.  It is evident that there are at least some cases
+ for which this definition fails, that is, the wrong 
+ revision may be found by `cvs diff' when used in combination
+ with `-r HEAD'.  You may wish to use `.trunk' rather than
+ `HEAD'.  The `.trunk' tag acts as a branch tag name for the
+ trunk.
+ 

is not correct nor consistent with this part:
  /*
!  * Special tags. 
!  * -rHEAD refers to the tip revision on the trunk, _except_ for
!  *  "cvs diff".  "cvs diff" interprets -rHEAD to mean the tip
!  *  revision of the current branch, however, that behavior is 
!  *  broken, because if the file has not been branched, that is,
!  *  the revision on the branch is the same one that's on the trunk
!  *  then the tip revision of the trunk is reported.  Also, it's
!  *  not clear (to me) what happens in the instance of a sticky
!  *  non-branch tag what -rHEAD is supposed to mean.  So, -rHEAD
!  *  is probably a lost cause, unless you redefine what it means.
!  *

from cvs.h, which I think is more correct...

So I need to fix that.

-- steve







__
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/

Re: Files created on Branch

[Kevin C. Castner]

1.10.8 is running on both server and client in pserver mode

On Fri, 16 Jun 2000, Eric Siegerman wrote:

> Which version of CVS?  I just tried this using 1.10.8 and it
> worked fine.
> 
> On Thu, Jun 15, 2000 at 01:58:39PM -0400, Kevin C. Castner wrote:
> > I have files that were created on a branch
> > 
> > (Create the file)
> > cvs co -r branch_name doc
> > cd doc
> > touch index.htm
> > cvs add index.htm
> > cvs commit index.htm
> > 
> > Now I try to merge the file back to the main trunk.
> > 
> > cd ..
> > rm -rf doc
> > cvs co doc
> > cd doc
> > cvs update -j branch_name
> > cvs commit index.htm
> > 
> > 
> > CVS then gives me the following error:
> > 
> > cvs server: cannot add file `index.htm' when RCS file 
>`/export/home/cvs/netops/doc/index.htm,v' already exists
> > cvs [server aborted]: correct above errors first!
> > 
> --
> 
> |  | /\
> |-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
> |  |  /
> [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD 
>   - Netcraft's "What's that site running?" service, 12-Jun-2000
> 

Re: can't "./configure"

[Mark Harrison]

> [chris@chris cvs]$ ./configure 
> bash: ./configure: No such file or directory

Look at the first line of the file, the one that usually
says something like

#!/bin/sh

You get the "No such file or directory" message if the file
on the first line is missing or over 30 characters.

HTH,
Mark.

--
Mark Harrison  AsiaInfo Holding, Inc.
[EMAIL PROTECTED]Beijing/Santa Clara