Re: Checking Out a Removed File
Jake Colman wrote: >I created a file on a branch, made numerous changes, and ulitimately removed >it from the branch. The file, of course, now exists only in the attic. I >now need to look at how I did something in that source module. How do I >checkout or gain access to a file that only exists in the attic? > >I know that CVS sees the file since a 'cvs co ' will tell me it is no >loner pertinent. A 'cvs log' will show me the complete commit log. But how >do I get the damned source?? > >TIA! > >...Jake > > > cvs checkout -p -r[last revision before remove] [filename] > [tempfile] This will checkout to standard out and redirect to tempfile. e.g. cvs checkout -p -r1.2.4.6 invisiblefile.java > visiblefile.java Hope this helps, Mike ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
(no subject)
FYI, the 'Win32' link on the Windows95/NT page http://cvshome.org/dev/codewindow.html points to ftp://ftp.cvshome.org/pub/cvs-1.10.5/windows/cvs.exe Which I guess is the wrong version! BTW. It has pointed to this version for a long long time, I guess no-one actually d/loads the Windows command line version? Everyone goes for WinCVS. Having checked, I don't seem to be able to find a pre-built windows version for either 1.10.8 or 1.11. Mike -- Mike Little Share what you know. Learn what you don't. ServicePOWER Business Solutions Ltd home: [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Cederqvist HTML Document Broken for Netscape
> -Original Message- > From: Tige D. Chastain [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 10, 2000 8:33 AM > To: [EMAIL PROTECTED] > Subject: Cederqvist HTML Document Broken for Netscape > > Hi, > > Thought I would let you all know that the document at > http://www.cvshome.com/docs/manual/cvs.html does not render in > Netscape. Taking a look at the HTML, it looks like not all of the > tables were closed, and as you know, Netscape adheres to the HTML DTD > tighter than IE. > > If other people that use Netscape can see it, please let me know, as > it indicates a problem on my end, and I am sorry for wasting > everyone's > time and filling their Inbox. > > Thanks, > > Tige D. Chastain > [EMAIL PROTECTED] Same for me with Netscape 4.72 on Windows NT. It shows a completely blank page. I saved the page and ran it through Web Lint which shows 12 errors/warnings. Mike -- Mike Little Share what you know. Learn what you don't. ServicePOWER Business Solutions Ltd home: [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: cvs doesn't see a correct path
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 05, 2000 6:08 PM > To: [EMAIL PROTECTED] > Subject: cvs doesn't see a correct path > [SNIP] > where bugid.bat has: > > SET PATH = D:\cygnus\CYGWIN~1\H-I586~1\bin;%PATH% > bash -c "c:/cvsroot/cvsroot/bugid.verify.sh" > > TIA, Julia > Are there really spaces around the "="? If so that is your problem. Windows cmd.exe/command.com shell does not use spaces around the equals in an env var assignment (unless you really want them to be there). You should be able to verify this by adding the following line to your bugid.bat file. SET >C:\temp.txt and then examine the output. If I'm correct you will probably find PATH=blah and PATH = blah in there. Hope this helps, Mike -- Mike Little Share what you know. Learn what you don't. ServicePOWER Business Solutions Ltd home: [EMAIL PROTECTED]
RE: Cvswebedit needs to be made GPL/open source. Any volunteers?
> -Original Message- > From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 11, 2000 2:48 PM > To: Free Software Foundation > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Cvswebedit needs to be made GPL/open source. Any > volunteers? > > On Tuesday 11 July 2000, at 2 h 0, the keyboard of Free > Software Foundation > <[EMAIL PROTECTED]> wrote: > > > If you GPL the program, we at gnu.org would be happy to > provide services to > > help your development. > > Well, the original poster apparently believed that he *had* > to transfer the > program to the FSF in order to put it under the GPL, which is > obviously wrong. > > > In fact, we are working right now on setting up > > services similar to those of of sourceforge, but targeted > for the free > > software community (sourceforge is only targeted for the open source > > community). > > Could you precise what it means? 99 % of the projects at > SourceForge are free > software, according to > <http://www.gnu.org/philosophy/license-list.html> and most are GPL. > > This really looks like FUD against SourceForge, but using a spurious > difference between "free" and "open source". > > I am not sure what this service will be ready, though. > > SourceForge works today but don't worry, their code is free > <http://sourceforge.net/projects/alexandria/>, you can use it :-) > Although this is getting off-topic... I'll respond. By their own reckoning ( http://sourceforge.net/softwaremap/trove_list.php?form_cat=13 ) less than 95% are OSI Approved. And as <http://www.gnu.org/philosophy/license-list.html> points out, OSI approval is *not* the same as GPL. There are many projects on Sourceforge that use licenses that are very definitely NOT compatible with the GNU GPL. Mike -- Mike Little Share what you know. Learn what you don't. ServicePOWER Business Solutions Ltd home: [EMAIL PROTECTED]
RE: Diff / Status problem
> -Original Message- > From: Markus Niebel [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 04, 2000 1:23 PM > To: [EMAIL PROTECTED] > Subject: Diff / Status problem > > > I asked it yesterday - I post it again since I want to know > what to do > against this behaviour. Found nothing in the docs / manuals. > > > Maybe this is an error which may come up in rare > circumstances and maybe > it is fixed yet (in which version???) > > We're using WinCVS 1.06 and commandline client 1.10.5 on NT > machines and > local access to the repo on a linux box via Samba. We detected the > following problem: > >dir1 > +subdir1 > |+---File1.hpp > |+---xxx > | > +---File1.hpp > +---xxx > > The File1.hpp-files were added and commited at the same time > and when I > make cvs status I can see the same time stamps. But the files have > definitly > different contents. When I copy File1.hpp from subdir1 over > File1.hpp in > dir1 and wincvs is not running then neither cvs status nor > cvs diff can > detect that the file has changed. This is wrong since the project in > dir1 > gets broken. > > Anyone get an idea what went wrong? I think your problem is may be caused by using the windows client over a samba file mount. You should use client server for the windows clients. Also 1.10.5 has bugs which are fixed in the latest version 1.10.8 Check the mailing list archives for previous threads on this subject. Hope this helps, Mike -- Mike Little Share what you know. Learn what you don't. ServicePOWER Business Solutions Ltd home: [EMAIL PROTECTED]
Re HEAD (was Re: ".trunk" patch refinement)
On 22 Jun 2000, at 15:59, Greg A. Woods wrote: >[ On Wednesday, June 21, 2000 at 22:50:26 (-0700), John P Cavanaugh wrote: ] >> - Delete the whole concept of HEAD, instead generalize it to something >> really useful and scaleable like >>.latest - For the latest version on a branch >>.base - For the version where the branch sprouted >> (ie. the base from the parent branch) > >Agree 101%! ;-) > >(There could be a bit of a chicken&egg problem to solve for ".base" >though -- I think you actually have to create it if you want it because >of the late branching optimisation, which is something you cannot avoid >if you want to maintain repo compatability.) > >> - Allow importing directly to the main branch, get rid of the >> import branch. > >I don't like the latter half of this point though. The magic vendor >branch is still a major time saver vs. the effort one would have to go >through to maintain local changes on a "normal" branch if the trunk is >the vendor's branch (i.e. re-branching as well as re-merging after every >import). It would also be more error prone to have the vendor branch on >the default branch -- people would be very likely to check it out and >work on it by accident. A thought... Could it be that the vendor branch works so well because 'cvs import'-ing sets the 'branch 1.1.1;' field in the RCS header? Whereas 'normal' cvs commands don't (and shouldn't). I vaguely remember something about MKS RCS not correctly working out the default branch (i.e HEAD) to commit to because it didn't set the 'branch' field. But I'm going back 6+ years now and it's all hazy! Mike -- Share what you know. Learn what you don't. Mike Little <[EMAIL PROTECTED]> work: <[EMAIL PROTECTED]> Web: http://www.ampersoft.co.uk PGP public key at http://www.ampersoft.co.uk/mike/mike.html
Re: Question
On 22 Jun 2000, at 13:53, Darryl VanDorp wrote: >I have a question for all you CVS gurus. > >I would like to when commiting a file to >have a short text file written to in the >same directory which contains the tag of file. I think you would have to have a wrapper script around cvs to do this. >The reason for this is (yes it's an obscure reason) >that i have MS Word docs in CVS that I would like >to add the current issue number to a footer automagically. >I can add the text file as an external file and have it print >the tag every time i print the file to get the current >Issue number (release #) > You may be able to call some routine in the WinCVS DLL to get this information from Visual Basic for Applications. It's a while since I did any VBA but I seem to remember you could call functions in DLLs Hope this helps, Mike -- Share what you know. Learn what you don't. Mike Little <[EMAIL PROTECTED]> work: <[EMAIL PROTECTED]> Web: http://www.ampersoft.co.uk PGP public key at http://www.ampersoft.co.uk/mike/mike.html
RE: ".trunk" patch refinement
> -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: Renegade CVS
On 17 Apr 2000, at 14:39, Sean Cavanaugh wrote: >In what sense is it active? I've been enlisted in it for quite some time and >haven't seen a single serious commit in a month. The activity has been getting >slower and slower as time goes on. Looking at the cvs diff since 1.10.8, it looks >like you more or less the only one left doing anything with it. > [SNIP] > >I also don't see my decision really as fragmentation at all, at the very least it >might get the people who apparently control the existing CVS to wake up, and do >something with it. >The worst case I see realistically with my project over the next few months, is >that all the various patches floating around the net, many of which are good and >useful, can be accessible to a wider audience and in a centralized place, get >backed-up automatically by the folks running sourceforge, and perhaps someday get merged into the real CVS. This method also solves getting the various patches working together, integrated, and tested, so the redundancy in work of people running multiple patches on their local site is eliminated. >The OTHER worst case is that the 'real' CVS continues the way it is going and >just dies off, and what I've got becomes at the very least a support area for fixing >bugs and getting minor features written. By then it will either get real >development, or eventually get replaced with a next generation open-source source management tool, which is inevitably going to happen someday. > >Right now we have ignored emails, and several documented aliases of which have >turned into blackholes, which both translate into ignored patches. This mailing list >lags 90 minutes every time I post to it which really hurts its usefulness. I'm sure >that can get fixed with some administrative effort, but its beyond my control. > >I love the program, I've been using it for quite a few years. I just have a >giant itch to scratch and nowhere to go, as do a few others. I actually plan on real >CVS becoming active again. I plan to only take patches based against 1.10.8 and any >future official CVS releases, which will help quite a bit in getting them back-ported over in the real CVS project if it ever happens. If that doesn't happen, well then RCVS becomes the 'real deal'. win-win if you ask me, the GPL is magic like that :) > > Sean, I cannot find anything to disagree with in your sentiments. I too have been frustrated by the lack of 'movement' of CVS. I was also disappointed with the buy-out of Cyclic by SourceGear, who revamped the website (making it look prettier but seem to have less information (or at least it was harder to navigate). And in turn now bought by OpenAvenue who apart from two messages to this mailing list and the press release on their website (only pointed to by SourceGear's site) have been deafiningly silent on the subject. I can only presume, by the way, that SourceGear bought Cyclic (and thus CVS -- sort-of) because of some plans to do with CodeCatalog. But I get the impression that OpenAvenue are mainly interested in CodeCatalog. I note that CVS is not listed as one of the projects hosted at 'LinuxAvenue.com' Hey, wait a minute, I've just noticed that they mention cvs on their oh-so-pretty image map of the OpenAvenue village. Clicking on the 'Cyclic.com -- Home of CVS' signpost (twice) takes you to... SourceGear.com! That's gotta be progress ;-) Enough sarcasm, back to the regular program... Mike -- Share what you know. Learn what you don't. Mike Little <[EMAIL PROTECTED]> work: <[EMAIL PROTECTED]> Web: http://www.ampersoft.co.uk PGP public key at http://www.ampersoft.co.uk/mike/mike.html
Re: Renegade CVS
On 17 Apr 2000, at 15:56, Larry Jones wrote: >Sean Cavanaugh writes: >> >> I've decided its past time to setup an active CVS repository for CVS, so >> I've created my own on sourceforge called 'Renegade CVS', the project name >> is rcvs. > >If people want to fork CVS that's OK with me, but I hasten to point out >that there *is* an active CVS repository (at cvs.cyclic.com), a group of >developers, and ongoing maintenance. > One would be hard pressed to believe it! I see postings to this mailing list and bugs-cvs indicating you and others have applied bug fixes and so on. But how is it possible to find out which bug fixes have been applied? Yes, I know I can use cvs to get all the source. But I'm behind a firewall at work, where I really want it. and if I was to get the source from home (I have done it before), I've still got to get it work (it's too big to fit on a floppy). Plus it takes a not insubstantial time to download and I have to pay for every second of my online time. Can we have daily snapshots, tar-ed and gzip-ed, of the source tree? I'm sure a cron job could be used to do this? In fact didn't you say that the source tree is built daily on all the supported platforms? Surely it's not too difficult to package those binaries for each platform into a tarball and put that into the ftp directory (over-writing yesterdays snapshot would be fine). Ditto for the source tree. Plus an online link to the changelog would be good. And some idea of current and future plans would be good. Mike, -- Share what you know. Learn what you don't. Mike Little <[EMAIL PROTECTED]> work: <[EMAIL PROTECTED]> Web: http://www.ampersoft.co.uk PGP public key at http://www.ampersoft.co.uk/mike/mike.html
Re: Branch Locking
On 20 Mar 2000, at 14:38, Adam Bidema wrote:
>
> I am trying to make it so I can lock a branch. I have searched through the
> code to find a centralized place where I can determine the branch a user is
> using on the server side, but can not find where I would add this code.
>
> Any help in finding this place, or another way to lock a branch would be
> much appreciated.
>
> Thanks,
> --Adam
>
I recently installed the Alternate Info patch by John P Cavanaugh
<[EMAIL PROTECTED]>. Which you should be able to find in the
archives of this mailing list.
That gives you a different format for the information passed to your commitinfo
and taginfo scripts, which includes the branch name (or 'main' for the trunk).
I then added a bit of code to my perl commitinfo script which checked another
file to see if the branch was 'locked'.
I don't use this extra information for my taginfo script.
There are a couple of bugs in the patch, which I had to correct.
The first was a sprintf string with two many replaceable params.
Index: src/tag.c
===
RCS file: /spower/repository/cvs/ccvs/src/tag.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- src/tag.c 2000/02/25 17:40:42 1.2
+++ src/tag.c 2000/03/03 10:53:05 1.3
@@ -441,7 +441,7 @@
type_stat=(delete_flag ? "BT_DEL" : force_tag_move ? "BT_MOV" :
"BT_ADD");
else
type_stat=(delete_flag ? "RT_DEL" : force_tag_move ? "RT_MOV" :
"RT_ADD");
-sprintf(argBuf,"%s:%s:%s:%s",p->key,type_stat,p->data);
+sprintf(argBuf,"%s:%s:%s",p->key,type_stat,p->data);
run_arg (argBuf);
}
}
The second, concerned with adding new files was ok on linux but seg faulted
on Solaris 2.5
Index: src/commit.c
===
RCS file: /spower/repository/cvs/ccvs/src/commit.c,v
retrieving revision 1.3
diff -u -r1.3 commit.c
--- src/commit.c2000/03/03 10:53:04 1.3
+++ src/commit.c2000/03/20 10:41:02
@@ -1144,7 +1144,7 @@
{ tag_stat="main"; }
else
{ tag_stat=li->tag; }
-sprintf(argBuf,"%s:%s:%s:%s",p->key,type_stat,tag_stat,li->rev_old);
+sprintf(argBuf,"%s:%s:%s:%s",p->key,type_stat,tag_stat, ((li->rev_old) ?
li->rev_old : ""));
run_arg (argBuf);
}
}
I can send you my scripts (and the one I wrote to manipulate the branchlock
file) if you wish.
Mike
--
Mike Little
Share what you know. Learn what you don't.
ServicePOWER Business Solutions Ltd
home: [EMAIL PROTECTED]
Re: removing the need for "cvs add file" to contact the server....
On 6 Mar 2000, at 9:37, Noel L Yap wrote: > [EMAIL PROTECTED] on 2000.03.03 16:04:27 > >[ On Friday, March 3, 2000 at 11:18:50 (-0500), Noel L Yap wrote: ] > >> Subject: Re: removing the need for "cvs add file" to contact the server > >>[SNIP] > >> What do you think it does in order for > >> it to work on future files? > > > >That is irrelevant. We're (or at least I am) talking about a concept > >here, not its implementation. > > > >Conceptually "cvs watch" operates only on files, regardless of how they > >are specified, just as "cvs ci" and other similar workspace sub-commands > >operate only on files. > > OK, but regardless of the implementation, "cvs watch" must operate on > directories in order to achieve this future inheritence. Noel, How about trying this concept: cvs watch evaluates 'cvs watch dir' whenever it needs to, so that new files will also be watched. If you think of it that way, then you can see that it is no different than 'cvs commit dir' - which will commit changed/added files now and will also commit files added/changed in the future, when it is executed again. > Also, I just thought of a couple of cases that might need discussion: > echo "dir" >.cvsignore > mkdir dir > cd dir > touch file > cvs add file > > and, a little different: > echo "dir0" >.cvsignore > mkdir -p dir0/dir1 > cd dir0/dir1 > touch file > cvs add file > > Where, if anyplace, will CVS admin subdirectories get created? > Now *this* is constructive. Greg, is this a case you have covered? And have you coded any of this yet? I'm quite eager to see it. Mike -- Mike Little Share what you know. Learn what you don't. ServicePOWER Business Solutions Ltd home: [EMAIL PROTECTED]
Re: removing the need for "cvs add file" to contact the server....
On 14 Feb 00, at 12:23, John Macdonald wrote: >... and they all ignore all of the files and sub-directories of any >directory that doesn't contain a CVS sub-dir (i.e. any directory that >is not part of the cvs-managed work area is totally ignored). They >quietly return from such a directory without doing any other portion >of the cvs operation as soon as it has been determined that the >directory is not part of the cvs-managed work area. Are we still talking about 'cvs add' here? If cvs add worked in *exactly* the same way as most of the other commands, that is; ignore all of the files and sub-directories not part of the cvs-manages work area, it wouldn't be much use would it? Mike -- Share what you know. Learn what you don't. Mike Little <[EMAIL PROTECTED]> work: <[EMAIL PROTECTED]> Web: http://www.ampersoft.co.uk PGP public key at http://www.ampersoft.co.uk/mike/mike.html
RE: CVS File Locking
On 14 Feb 00, at 16:01, Jerry Nairn wrote: > >> From: Mike Little [mailto:[EMAIL PROTECTED]] >> Sent: Sunday, February 13, 2000 3:24 PM > >> But on to CVS... >> >> First, my (revision control related) credentials: > >First, I'm unimpressed. I've been at this longer than you have. But an >appeal to superior experience or authority is simply a sign that you don't >have any more logical arguments to support your point. It is little better >than insulting the person you are debating. You misunderstood me. I was not seeking to impress, I was trying to show that I have had experience of several different types of revision control systems. In fact two each of the concurrency and locking flavour. I wanted to show that I had practical experience of 'both sides'. I apologize for making you think less of me. >Second, your experience is not part of the background for CVS. Most of your >points on CVS are well put. Thankyou. Mike -- Share what you know. Learn what you don't. Mike Little <[EMAIL PROTECTED]> work: <[EMAIL PROTECTED]> Web: http://www.ampersoft.co.uk PGP public key at http://www.ampersoft.co.uk/mike/mike.html
Re: CVS File Locking
nough rope...") Someone else suggested that symbolic links could be a problem, which Greg countered by agreeing that yes, symbolic links are a problem. They _are_ currently, without his proposal! Another responded with some non-specific mumble about mounted file systems. So you see, no-one has yet managed to prove that recursing upwards is dangerous in other than exceptional circumstances. But then other CVS commands are dangerous in exceptional circumstances. Mike -- Share what you know. Learn what you don't. Mike Little <[EMAIL PROTECTED]> work: <[EMAIL PROTECTED]> Web: http://www.ampersoft.co.uk PGP public key at http://www.ampersoft.co.uk/mike/mike.html
