[comp.sys.hp] Bugs in RCS ??

vic@zen.co.uk (Victor Gavin) (10/12/89)

[`uname -a` == "HP-UX zen A.B3.10 D 9000/840 5067"]

When using RCS, I have come across the following bugs which others may
like to know about so that they can avoid them.

1) If you have a central RCS directory somewhere, which has many links
to it, and you check a file out as locked in one of the directories
with a link, you can also check it out as locked in a totally
different directory, as long as there isn't a copy of the file in the
second directory.

ie The locking doesn't work, as it is dependent upon having a
writeable copy of the file in the current directory.

2) If you have a file checked out as locked, but which hasn't been
modified, when you check it in it will ask

	File blip is unchanged with respect to revision 1.1
	checkin anyway? [ny](n): 

and if you answer `n', the source file will get *deleted*. Worse still
the lock will still be set so you cannot check out anymore locked
versions.


........
As an aside, maybe someone from HP would like to comment on why some
of the products they ship are much older versions of those available
from other manufacturers (in this case, RCS from HP is dated May 1983,
and there are certainly much newer versions available).


And as a wish, can't we have some more useful stuff available on the
contrib tape.

F'rinstances:

  *) a complete set of compiled and ``working'' GNU stuff,
  *) commands which are non-supported but available on other machines
     eg rdump/rrestore, rpc.lockd, compact etc.
  *) anything else that is executable :-)


			vic
--
Victor Gavin						Zengrange Limited
vic@zen.co.uk						Greenfield Road
..!mcvax!ukc!zen.co.uk!vic				Leeds England
+44 532 489048						LS9 8DB

runyan@hpirs.HP.COM (Mark Runyan) (10/14/89)

>/ vic@zen.co.uk (Victor Gavin) /  8:16 am  Oct 12, 1989 /
>[`uname -a` == "HP-UX zen A.B3.10 D 9000/840 5067"]

Thanks for the ID...

>1) If you have a central RCS directory somewhere, which has many links
>to it, and you check a file out as locked in one of the directories
>with a link, you can also check it out as locked in a totally
>different directory, as long as there isn't a copy of the file in the
>second directory.
>
>ie The locking doesn't work, as it is dependent upon having a
>writeable copy of the file in the current directory.

I'm confused about this.  If you check a revision out as "locked",
the lock is stored in the RCS file (The ",v" file).  The writeableness
of the working file isn't what sets the lock.  It is also my impression
that the semaphore file is put where the RCS file is, so I don't think
you are talking about that.  Could you be referring to the fact that
RCS does not work well with links (hard or soft)?  It seems that since
RCS tends to completely replace the RCS file, any links you try to
establish for the ",v" file are broken.  Perhaps a work around would
be to use the RCS directory/file feature.

>2) If you have a file checked out as locked, but which hasn't been
>modified, when you check it in it will ask
>
>	File blip is unchanged with respect to revision 1.1
>	checkin anyway? [ny](n): 
>
>and if you answer `n', the source file will get *deleted*. Worse still
>the lock will still be set so you cannot check out anymore locked
>versions.

But you can check out the version you already have locked by using
the "-r" option.  I'm not sure why the file is deleted or whether
that is the right thing to do or not, but if it is exactly the
same as the revision you already have locked, then you can recover
by checking out the version you have locked by using the "-r" option.
If you wish to clear a lock, you can use the "rcs -u" command to
remove a lock that you currently have.

>As an aside, maybe someone from HP would like to comment on why some
>of the products they ship are much older versions of those available
>from other manufacturers (in this case, RCS from HP is dated May 1983,
>and there are certainly much newer versions available).

Well, just as an attempt to spread the rumor further, it is because
we haven't obtained a copy of the new stuff that we can resell as
part of product...   I think the problem is that later versions of
RCS are under GNU's copyleft and HP lawyers are still completely
sure about what that means if we want to include RCS with HP-UX.

>And as a wish, can't we have some more useful stuff available on the
>contrib tape.

Hope that someday we can meet your requests.  The more people that
ask for a contrib tape, the better the chances of one being built.

kamat@uceng.UC.EDU (Govind N. Kamat) (10/15/89)

In article <4640018@hpirs.HP.COM> runyan@hpirs.HP.COM (Mark Runyan) writes:

   >And as a wish, can't we have some more useful stuff available on the
   >contrib tape.

   Hope that someday we can meet your requests.  The more people that
   ask for a contrib tape, the better the chances of one being built.

Let me add my vote for that.  And, in the meantime, can't we have the
stuff on the latest contrib tape made available for anonymous ftp?

--
Govind N. Kamat 			College of Engineering
kamat@uceng.UC.EDU			University of Cincinnati
					Cincinnati, OH 45221, USA

garvey@cmic.UUCP (Joe Garvey) (10/17/89)

> 
> Let me add my vote for that.  And, in the meantime, can't we have the
> stuff on the latest contrib tape made available for anonymous ftp?
> 
> --
> Govind N. Kamat 			College of Engineering
> kamat@uceng.UC.EDU			University of Cincinnati
> 					Cincinnati, OH 45221, USA

Here, Here. An excellent idea. Let's not forget any of the other contrib
tapes, like the X-contrib tape. Maybe the Response center folks could do
this for us, please?



Joe Garvey                UUCP: {uunet,backbone}!amdahl!pyramid!mips!cmic!garvey
California Microwave      Internet: {ames}!mips!cmic!garvey
990 Almanor Ave
Sunnyvale, Ca, 94086      408-720-6439 (let it ring)

We just appeared in the maps. If your site is up to date, we're there.

vic@zen.co.uk (Victor Gavin) (10/18/89)

In article <212@cmic.UUCP> garvey@cmic.UUCP (Joe Garvey) writes:
>> Let me add my vote for that.  And, in the meantime, can't we have the
>> stuff on the latest contrib tape made available for anonymous ftp?
>> Govind N. Kamat
>Here, Here. An excellent idea. Let's not forget any of the other contrib
>tapes, like the X-contrib tape. Maybe the Response center folks could do
>this for us, please?
>Joe Garvey

How about it HP-UK, anonymous ftp from the Response Centre?

And while I'm wishing for the stars, how about an email address for sending
in programs that show off bugs, rather than `faxing' them in so the engineer
can type them in.


			vic
--
Victor Gavin						Zengrange Limited
vic@zen.co.uk						Greenfield Road
..!mcvax!ukc!zen.co.uk!vic				Leeds England
+44 532 489048						LS9 8DB

belkin@teecs.UUCP (Hershel Belkin) (10/20/89)

/ teecs:comp.sys.hp / vic@zen.co.uk (Victor Gavin) /  4:53 am  Oct 18, 1989 /

>And while I'm wishing for the stars, how about an email address for sending
>in programs that show off bugs, rather than `faxing' them in so the engineer
>can type them in.

YES, YES!!  Actually, I _have_ e-mailed files to the Western Response 
Center (although I almost had to beg them to find an address that worked :-)
That experience (a 25-page file which they asked me to FAX) was great, and
they even e-mailed me a patch!!

The Atlanta Center is reportedly soon going to have a usenet address for
such purposes (or so they told me on my last call...)

I just want to add my voice to this request; so much time is wasted due
to missed call-backs, etc.

-- 
+-----------------------------------------------+-------------------------+
| Hershel Belkin               hp9000/825(HP-UX)| ...!{lsuc}!teecs!belkin |
| Test Equipment Engineering Computing Services |     Phone: 416 246-2647 |
| Litton Systems Canada Limited       (Toronto) |       FAX: 416 246-5233 |
+-----------------------------------------------+-------------------------+

vic@zen.co.uk (Victor Gavin) (10/25/89)

> In reply to my article, Mark Runyan (runyan@hpir.hp.com) wrote
>> In a previous article I wrote

>>1) If you have a central RCS directory somewhere, which has many links
>>to it, and you check a file out as locked in one of the directories
>>with a link, you can also check it out as locked in a totally
>>different directory, as long as there isn't a copy of the file in the
>>second directory.
>>
>>ie The locking doesn't work, as it is dependent upon having a
>>writeable copy of the file in the current directory.
>
>I'm confused about this.  If you check a revision out as "locked",
>the lock is stored in the RCS file (The ",v" file).  The writeableness
>of the working file isn't what sets the lock.

But it does inhibit creation of new locked/writeable files.

An example is always useful:

	(2)vic: mkdir RCS
	(2)vic: touch abc
	(2)vic: /usr/bin/ci -l abc
	RCS/abc,v  <--  abc
	initial revision: 1.1
	enter description, terminated with ^D or '.':
	NOTE: This is NOT the log message!
	>> 
	done
	(2)vic: ls -al abc
	-rw-------   1 vic      software       0 Oct 25 15:42 abc
	(2)vic: rm abc
	(2)vic: grep lock RCS/abc,v
	locks    vic:1.1; strict;

[Note: The file is marked as locked within the RCS `,v' file]

	(2)vic: /usr/bin/co -l abc
	RCS/abc,v  -->  abc
	revision 1.1 (locked)
	done

[but still allows us to check it out again with a lock.]

	(2)vic: /usr/bin/co -l abc
	RCS/abc,v  -->  abc
	revision 1.1 (locked)
	writable abc exists; overwrite? [ny](n): n
	co warning: checkout aborted.

[and only if there is a writeable version in the current directory,
 does it complain.]

So what I hope I've proved is that the locking mechanism doesn't
actually pay any attention to the file status within the RCS file.


>>2) If you have a file checked out as locked, but which hasn't been
>>modified, when you check it in it will ask
>>
>>	File blip is unchanged with respect to revision 1.1
>>	checkin anyway? [ny](n): 
>>
>>and if you answer `n', the source file will get *deleted*. Worse still
>>the lock will still be set so you cannot check out anymore locked
>>versions.
>
>But you can check out the version you already have locked by using
>the "-r" option.  I'm not sure why the file is deleted or whether
>that is the right thing to do or not, but if it is exactly the
>same as the revision you already have locked, then you can recover
>by checking out the version you have locked by using the "-r" option.


Since I said ``no I don't want to check this file in'' I expect the
program to behave as if I never asked it to do anything. If I said to
you: ``don't check in any files which haven't changed'', you wouldn't
interpret that as meaning ``delete all those that haven't changed'',
would you ?


>If you wish to clear a lock, you can use the "rcs -u" command to
>remove a lock that you currently have.

You'd prefer it if I make up for the deficiencies in a piece of
software by doing the work myself?

If there is a problem, it should be fixed.

>>As an aside, maybe someone from HP would like to comment on why some
>>of the products they ship are much older versions of those available
>>from other manufacturers (in this case, RCS from HP is dated May 1983,
>>and there are certainly much newer versions available).
>
>Well, just as an attempt to spread the rumor further, it is because
>we haven't obtained a copy of the new stuff that we can resell as
>part of product...   I think the problem is that later versions of
>RCS are under GNU's copyleft and HP lawyers are still completely
>sure about what that means if we want to include RCS with HP-UX.

This sounds reasonable. Might I suggest that for situations like this
HP supply the product (inc. src for GNU stuff) on a seperately contrib
tape that is available to anyone for a nominal fee...remember the GNU
licence doesn't forbid you from charging a reasonable sum, all they
stop you doing is keeping the source to yourself.