File added to branch can exist before creation date
Submitter-Id: net Originator: Richard Earnshaw Organization: net Confidential: no Synopsis: File added to branch can exist before creation date Severity: non-critical Priority: medium Category: cvs Class: sw-bug Release: cvs-1.11 Environment: System: NetBSD shark1 1.5ZA NetBSD 1.5ZA (SHARK) #91: Fri Feb 8 14:24:26 GMT 2002 rearnsha@shark1:/usr/src/sys/arch/arm32/compile/SHARK arm32 Unknown version of remote server Description: This was noticed while trying to add a file on a remote CVS server (sorry, don't know what version it is running). Assume we have a project which is developing down the trunk, and then on, say, 1/1/02 a branch 'foo' is created. Now on 2/2/02 we add the file 'bar' on the trunk. This file will exist only on the trunk. Then on 3/3/02 we add a file bar on branch 'foo'. If we try to check out branch foo for a date between 2/2/02 and 3/3/02 the trunk version of 'bar' will be retrieved. How-To-Repeat: See above description Fix: When file is added to the branch when that branch didn't exist on that file before, a dead file should be added first with the same date and time as the file it is 'branching' from. ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
[EMAIL PROTECTED] (Larry Jones) writes: SCCS can retrieve any revision in one pass through the file. As you say, there are the equivalent of #ifdefs that specify which revisions include the following lines , so there's very little processing time, it's mostly just I/O time. CVS as currently implemented has to read the entire RCS file before doing anything, so I'd be very surprised if it's significantly faster. It was not the case formerly that CVS read the entire RCS file to retrieve the head revision. I haven't looked at the current code. But previously CVS would just read the RCS header (including all the tags), and then only read revision text as required. Ian ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Hi Michael. I see a problem with the CVS code as distributed. That is, it has a single csh script which is both slow and makes the CVS code-base depend on an additional unix utility when it doesn't have to. Well, it's only a contributed utility, not a core part of the CVS code as distributed. All the Linux distributions I have access too include sccs2rcs as part of the CVS package because it is distributed as part of the CVS tar ball. Because of that, I consider it part of CVS. I run Red Hat 6.2 here, with CVS installed from RPM. I've just checked, and no such file exists either on my system or in the CVS RPM. Could you advise where it's gone please? I believe I addressed both of these problems with my re-write of the script in perl. No, you did not. Only a translation to POSIX Shell or C would have addressed both problems. If somebody wishes to send me a copy of the script in question, I'll translate it to bash for you if that's possible. Best wishes from Riley. ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Ian Lance Taylor writes: It was not the case formerly that CVS read the entire RCS file to retrieve the head revision. I haven't looked at the current code. But previously CVS would just read the RCS header (including all the tags), and then only read revision text as required. That's partially true -- CVS does just read the header to start, but whenever it needs to read any revision text, it reads all of it. -Larry Jones Even though we're both talking english, we're not speaking the same language. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
On Fri, 8 Mar 2002, Riley Williams wrote: All the Linux distributions I have access too include sccs2rcs as part of the CVS package because it is distributed as part of the CVS tar ball. Because of that, I consider it part of CVS. I run Red Hat 6.2 here, with CVS installed from RPM. I've just checked, and no such file exists either on my system or in the CVS RPM. Could you advise where it's gone please? I don't think you have the rpm distributed with Red Hat 6.2: $ rpm -qlp cvs-1.10.7-7.i386.rpm | grep sccs /usr/lib/cvs/contrib/sccs2rcs If somebody wishes to send me a copy of the script in question, I'll translate it to bash for you if that's possible. Sounds good to me, I'll send you the original csh version to you via private email and we'll see what Larry has to say about it. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
On Thu, 7 Mar 2002, Greg A. Woods wrote: Why convert from SCCS? I don't have any larger projects managed by SCCS, but for all the small ones I have there's not much point to changing over to RCS (or CVS) -- I just keep using SCCS :-) Ok, well this is moving away from the topic I'd prefer, that being the sccs2rcs script issue, but... Well, at this moment, we have 1835 SCCS directories and an absolute ton of source. SCCS isn't the fastest thing to use -- I believe RCS blows it out of the water in the most common case of getting the most recent version out of the repository -- especially on NFS mounted disk, this gets to be an issue. Perhaps more importantly, our development is moving almost entirely to Linux and the free SCCS support on Linux is lacking (CSSC isn't recommended by the author). We'd also like to completely change our development scheme and move to CVS with maintainers of various subsystems accepting patches from developers similar to the free software model, but in-house. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Subject: Re: sccs2rcs to perl To: [EMAIL PROTECTED] (Michael Sterrett -Mr. Bones.-) Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] From: [EMAIL PROTECTED] (Larry Jones) List-Archive: http://mail.gnu.org/pipermail/bug-cvs/ Date: Fri, 8 Mar 2002 13:39:01 -0500 (EST) Michael Sterrett -Mr. Bones.- writes: Well, at this moment, we have 1835 SCCS directories and an absolute ton of source. SCCS isn't the fastest thing to use -- I believe RCS blows it out of the water in the most common case of getting the most recent version out of the repository -- especially on NFS mounted disk, this gets to be an issue. You may find your belief to be mistaken -- I can't think of any reason to expect CVS to be faster than SCCS, unless you plan to switch from NFS access to CVS's client/server mode (which I would strongly advise -- we have had lots of reports of repository corruption caused by NFS interoperability problems). I believe what he is refering to is that the more SCCS will get slower the more revisions you have in a file. Getting a file from RCS/CVS should be a constant time event for the latest version because RCS/CVS stores the latest revision verbatim. However, as I understand it, SCCS saves each version as #ifdefs. I don't think it stores a complete copy of the latest revision. As such, it will have to calculate what is in the latest version and how long this takes will depend on how many revisions you have. -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Stephen Rasku writes: I believe what he is refering to is that the more SCCS will get slower the more revisions you have in a file. Getting a file from RCS/CVS should be a constant time event for the latest version because RCS/CVS stores the latest revision verbatim. However, as I understand it, SCCS saves each version as #ifdefs. I don't think it stores a complete copy of the latest revision. As such, it will have to calculate what is in the latest version and how long this takes will depend on how many revisions you have. SCCS can retrieve any revision in one pass through the file. As you say, there are the equivalent of #ifdefs that specify which revisions include the following lines , so there's very little processing time, it's mostly just I/O time. CVS as currently implemented has to read the entire RCS file before doing anything, so I'd be very surprised if it's significantly faster. -Larry Jones Life's a lot more fun when you're not responsible for your actions. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Larry Jones wrote: Stephen Rasku writes: I believe what he is refering to is that the more SCCS will get slower the more revisions you have in a file. Getting a file from RCS/CVS should be a constant time event for the latest version because RCS/CVS stores the latest revision verbatim. However, as I understand it, SCCS saves each version as #ifdefs. I don't think it stores a complete copy of the latest revision. As such, it will have to calculate what is in the latest version and how long this takes will depend on how many revisions you have. SCCS can retrieve any revision in one pass through the file. As you say, there are the equivalent of #ifdefs that specify which revisions include the following lines , so there's very little processing time, it's mostly just I/O time. CVS as currently implemented has to read the entire RCS file before doing anything, so I'd be very surprised if it's significantly faster. Really? Looking at a sample ,v file I can see the latest revision stored intact near the top of the file. I don't know why it would have to read the other revisions. -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
[ On Friday, March 8, 2002 at 13:24:16 (-0500), Michael Sterrett -Mr. Bones.- wrote: ] Subject: Re: sccs2rcs to perl Well, at this moment, we have 1835 SCCS directories and an absolute ton of source. SCCS isn't the fastest thing to use -- I believe RCS blows it out of the water in the most common case of getting the most recent version out of the repository -- especially on NFS mounted disk, this gets to be an issue. You really had better research that a bit more. You are apparently suffering from belief in a widely disseminated myth (caused by an incorrect answer remaining in the comp.unix.questions FAQ since 1992, perhaps because my colleague Ted Timar, who maintained that FAQ, was not a huge fan of SCCS). SCCS is not necessarily slower than RCS -- and RCS _is_ still slower than SCCS in many cases, esp. if you use one of the more modern SCCS implementations, such as Larry McVoy's BitSCCS, or Ross Ridge's MySC, or even the GNU CSSC. A common misconception is that SCCS baselines the initial version and keeps deltas to create newer versions. Actually, SCCS interleaves all the versions; this is not as bad as the common misconception, but it _can_ make new development get progressively slower. Note though that if you don't use the head of the trunk for development then RCS can degrade rather nastily In other words you'd better benchmark before you decide on that assumption alone. BTW, what the heck are you doing with putting any kind of repository on an NFS partition!?!?!?!? Perhaps more importantly, our development is moving almost entirely to Linux and the free SCCS support on Linux is lacking (CSSC isn't recommended by the author). The current maintainer of CSSC is overly careful. I've been using it happily for years, even on occasion interoperating with it and SunOS-4. We'd also like to completely change our development scheme and move to CVS with maintainers of various subsystems accepting patches from developers similar to the free software model, but in-house. Well, there could be benefits there, I grant you that! -- Greg A. Woods +1 416 218-0098; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
On Fri, 8 Mar 2002, Larry Jones wrote: SCCS can retrieve any revision in one pass through the file. As you say, there are the equivalent of #ifdefs that specify which revisions include the following lines , so there's very little processing time, it's mostly just I/O time. CVS as currently implemented has to read the entire RCS file before doing anything, so I'd be very surprised if it's significantly faster. Larry -- When was the last time you used SCCS for a large project? RCS is *way* faster, at least at getting the latest version of the file for edit. It's not super easy for me to test right now, but I imagine CVS is equally quick. All of this discussion is interesting to me, but what I'd really like to see is something done about the sccs2rcs script. Is there any real gain in continuing to ship it with CVS given the fact that it doesn't seem to be maintained by anyone (at least, no one wants to take responsibility for it) and it doesn't pertain to the main functionality of CVS? Why not move it to http://www.loria.fr/~molli/cvs-index.html as contrib/README suggests and out of the official CVS tarball releases? What's your opinion of this idea? Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Michael Sterrett wrote: All of this discussion is interesting to me, but what I'd really like to see is something done about the sccs2rcs script. Is there any real gain in continuing to ship it with CVS given the fact that it doesn't seem to be maintained by anyone (at least, no one wants to take responsibility for it) and it doesn't pertain to the main functionality of CVS? Why not move it to http://www.loria.fr/~molli/cvs-index.html as contrib/README suggests and out of the official CVS tarball releases? What's your opinion of this idea? Personally, I think we should continue to include the current script. I used it successfully to convert our SCCS code repository from SCCS to CVS without any problems and I think a lot of people have. -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerWeb:http://www.pop-star.net/ TGI Technologies ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Stephen Rasku writes: Really? Looking at a sample ,v file I can see the latest revision stored intact near the top of the file. I don't know why it would have to read the other revisions. I didn't say it has to, I said it does. It makes the code simpler to get all the data from the RCS file into a nice internal data structure. -Larry Jones I like maxims that don't encourage behavior modification. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Michael Sterrett -Mr. Bones.- writes: When was the last time you used SCCS for a large project? RCS is *way* faster, at least at getting the latest version of the file for edit. It's not super easy for me to test right now, but I imagine CVS is equally quick. You imagine wrong. There are significant differences between RCS and CVS's RCS library. -Larry Jones Temporary insanity! That's all it was! -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
The Delete Police are at it again!
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00A4_40B14D4A.A3765B72
Re: sccs2rcs to perl
[EMAIL PROTECTED] (Larry Jones) writes: Ian Lance Taylor writes: It was not the case formerly that CVS read the entire RCS file to retrieve the head revision. I haven't looked at the current code. But previously CVS would just read the RCS header (including all the tags), and then only read revision text as required. That's partially true -- CVS does just read the header to start, but whenever it needs to read any revision text, it reads all of it. No, CVS doesn't read the whole RCS file. Look closely at RCS_checkout and RCS_deltas. They stop reading once they have the text they need. Ian ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
