repository replication idea (was RE: New email address)
Riley Williams wrote: > Hi Derek. [...] > > > > Brian Behlendorf tells me that Collab Net will be supporting the > > bandwidth and hardware for cvshome.org for an indefinite period. > > Are you sure of this? As of yesterday morning, I've been unable to get > to cvshome.org either by web or cvs pserver, so as far as I can tell, > it's already dead... Same here... I can't get pserver to work either, "Connection refused" Whether it's "already dead", or if this is just a temporary glitch, these interesting times we live in bring to mind an idea I had awhile back, and which I'll mention now in case somebody wants to take the ball and run with it. (or maybe somebody already did?) It occurred to me that lots of GPL-ish licensed software is hosted in CVS servers run by companies which might someday cease to be. For example, what would happen if VA Linux (or whatever it's called now), and thus Sourceforge, suddenly disappeared? For any project of interest, somebody would probably have done a recent checkout, so what's really at risk is not so much the current state of the source code as the history, the tags, the branches, and all the CVS-ish information that is not included in a source tarball. It would be nice if there ware a simple way to replicate a repository. It occurs to me that it is almost possible to write a program to do this requiring no special setup on the server side. The only piece missing (I think) is a way to find all the files which are, or ever were, present in the repository. Assuming you had such a list of files, you could replicate a remote CVS repository in the following way: For every file on the list, do a "cvs log" This would give you a list of revisions, and all the tags. Then you could, one by one, check out (or diff) each rev of each file from the remote repository, and check it into a local repository. First do the trunk then create branch tags off the trunk, then do each branch, then create any branch tags off those branches, etc. Finally apply all the static tags. You'd have to worry about sticky options, and log messages too, of course, but, it is possible to write a script to do all this. The piece that's missing is the list of all files in the repository. "cvs rdiff -s -r 0" almost gets it, but not quite. I guess you could do something vaguely like for tag = every tag found by cvs log do "cvs rdiff -s -r 0 -r tag" >> filelist done little_awk_script < filelist | sort | uniq > newfilelist And get pretty close, reasoning that every file of importance would have been tagged with a static tag at one time or another, But that's pretty brute-forceful. Just an idea for anybody that's paranoid about their voodoo-economcially funded remote CVS repository suddenly disappearing. -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How well does CVS handle other types of data?
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > [ On Friday, July 13, 2001 at 14:20:07 (-0500), Cameron, > Steve wrote: ] > > Subject: RE: How well does CVS handle other types of data? > > > > Re-reading my original message, I see I failed to mention > those binary > > files were 3rd party object code for which we do not have access to > > the source code, yet which are nevertheless required to > build our product. > > OK, so what's the problem with using "-L" (and "-I" if necessary) to > simply point at the right version of that code (and headers) in the > build process!?!?!?!?!? > > Putting object code into CVS is just plain silly and pointless> The point of it is that it works as-is for me today. I avoid the effort of thinking up, (or copying), implementing, testing, backing up, etc. some other method or storing/retrieving these files. You're providing a solution to a problem which I don't have. The satisfaction of virtuously not storing unmergeable files in CVS isn't enough of a motivator to get me to quit doing it, and no other motivators have materialized. -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How well does CVS handle other types of data?
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > [ On Friday, July 13, 2001 at 08:39:09 (-0500), Cameron, > Steve wrote: ] > > Subject: RE: How well does CVS handle other types of data? > > > > On the issue of whether storing binary files in CVS is a good > > idea, vs. trying to use "something else" in conjuction with CVS, > > my experience has been that putting the binary files in CVS works > > well enough, (apart from the above problem.) The advantage, > > (having one tag that you can do a "cvs checkout" and get > _everything_ > > you need.) outweighs the disadvantage, (that files are not > mergeable) > > for us anyway. > > That's a moot point Steve. If your build system (makefiles, scripts, > source to tools, etc.) is also checked in to your CVS tree > then it will > be tagged and you can "cvs checkout; make" and you'll still ``get > _everything_'' but you won't have *any* problems with binary files in > CVS! Re-reading my original message, I see I failed to mention those binary files were 3rd party object code for which we do not have access to the source code, yet which are nevertheless required to build our product. (Probably still not a good enough excuse for you, Greg, I know, but that's ok. :-) Of course if you can derive a file it shouldn't go into CVS at all, I didn't mean to imply otherwise. My binaries are not derivable by me. Probably I should have just left out the 2nd paragraph of my original email. -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How well does CVS handle other types of data?
Just thought I'd mention one problem with trying to store binary files in CVS that nobody has mentioned yet It's not too hard to get diff to run out of memory with binary files, (compared to ascii files.) I have one file in my repository that I can't commit to because of this. Luckily, it's obsolete, and the commit that I would like to do is a "cvs remove". But I can't, so it gets checked out all the time and ignored. Tolerable, but not ideal. (The file _is_ rather huge to begin with, so maybe it doesn't actually come up that much.) On the issue of whether storing binary files in CVS is a good idea, vs. trying to use "something else" in conjuction with CVS, my experience has been that putting the binary files in CVS works well enough, (apart from the above problem.) The advantage, (having one tag that you can do a "cvs checkout" and get _everything_ you need.) outweighs the disadvantage, (that files are not mergeable) for us anyway. Probably this has something to do with the nature of our binaries, (always thrid party deliverables that we just check in, merging boils down to trivial selection.) That's how it's worked out for us anyway. YMMV. Back to lurk mode. -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
-r HEAD bug
R. Bresner wrote:
> We've just installed cvs 1.11 from 1.9 and are noticing a different
> behavior
> with -r HEAD. (client NT, server Solaris).
>
> When diffing a branched area, CVS is getting the head of a branch
> based on the revision of a file. We have many files that are branched,
> but have no changes in the branched area, and so still have a
> mainline-esq revision number. The problem occurs when we do a diff
> with -rHEAD, as the file is diffed to _mainline_, which is rarely as
> stable
> as our branches.
Hi,
"cvs diff" used with "-r HEAD" seems to be a little
screwy, IMHO.
There are some comments in sanity.sh around this area
and It tests for it, so I guess that makes it a feature
rather than a bug...:
to wit:
# But diff thinks that HEAD is "br1". Case (b) from cvs.texinfo.
# Probably people are relying on it.
dotest head-br1-diff "${testcvs} -q diff -c -r HEAD -r br1" ""
# With a nonbranch sticky tag on a branch,
# HEAD is the head of the trunk
dotest head-brtag-setup "${testcvs} -q update -r brtag" "[UP]
file1"
dotest head-brtag-update "${testcvs} -q update -r HEAD -p file1" \
"imported contents
add a line on trunk
add a line on trunk after trunktag"
# CVS 1.9 and older thought that HEAD is "brtag" (this was
# noted as "strange, maybe accidental"). But "br1" makes a
# whole lot more sense.
dotest head-brtag-diff "${testcvs} -q diff -c -r HEAD -r br1" ""
# With a nonbranch sticky tag on the trunk, HEAD is the head
# of the trunk, I think.
I have a patch which allows you to specify ".trunk" to
be an (almost) real branch name for the trunk (you can
commit to it, and everything else you could do with a branch
tag (except you can't delete the ".trunk" tag).
If you are interested in that,
http://www.geocities.com/dotslashstar/branch_patch.html
It also lets you specify the origin of a branch name by
"branchname.origin"
I gather, what you are trying to do is figure the changes that
have occurred on the branch, without regard for what
changes may have occurred on the trunk in the mean time.
Assuming you have tagged the beginning of your branch
(at the time you created the branch, you created a separate,
non-branch tag so you could refer to the beginning of the branch)
cvs rdiff -r branchpoint -r branch_tag modulename
Or, using my patch, (in case you didn't make such a
"branchpoint" tag)
"cvs rdiff -r branch_tag.origin -r branch_tag modulename"
Hope it helps.
-- steve
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to generate a revision list?
Ingolf Steinbach wrote: > has someone written an awk/perl/whatever script which > generates a table with (at least) the entries "local > file name", "revision", "date of checkin" from a static > tag and a locally checked out copy of a module? Perhaps you already know about this: cvs rdiff -s -r0 -rstatic_tag modulename which will give you the filenames and revision numbers, but not date of checkin -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Documentation suggested to clearer state restrictions to merging removed files
Nevermind, I already checked the case I was thinking of. From
my patch, (Duh!) (Thanks Derek P. for reminding me.)
+
+ dotest dotorigin41 "${testcvs} rdiff -s -r dot5.origin
-rdot5 mydir2" \
+ "${PROG} [a-z]*: Diffing mydir2
+ File mydir2/abc is new; current revision 1\.1\.2\.1
+ File mydir2/xyz is removed; not included in release tag dot5"
+
>
I wrote:
> > Hmm, this might have implcations for my ".origin" patch that I'll have
> to
> > look into,
> > if I didn't already consider it...
> >
> > http://www.geocities.com/dotslashstar/branch_patch.html
> >
> > -- steve
> > [...]
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Documentation suggested to clearer state restrictions to merging removed files
Hmm, this might have implcations for my ".origin" patch that I'll have to
look into,
if I didn't already consider it...
http://www.geocities.com/dotslashstar/branch_patch.html
-- steve
Derek R. Price wrote:
[...]
> Hmm. You're right, and the culprit seems to be that 'cvs tag
> tag_on_branch'
> run on the branch skips dead files (intentionally), so when a merge is
> attempted from a single static tag, only changes in files containing the
> tag
> are noticed and merged.
>
> Comments on the following addition to the "update options" node?
>
> revision which the working directory is based on, and
> the revision specified in the @samp{-j} option.
>
> +Note that using a single @samp{-j TAGNAME} option rather than
> +@samp{-j BRANCHNAME} to merge changes from a branch will
> +often not remove files which were removed on the branch since the dead
> +revisions do not contain the static tag. Use the branch tag to merge all
> +changes on the branch or use two static tags as merge endpoints to be
> sure
> +all intended changes are propagated in the merge.
>
> In addition, each @samp{-j} option can contain an optional
> date specification which, when used with branches, can
>
> Derek
[...]
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Client/server CVS
> I have downloaded the latest 1.11 sources and > compiled them on the AIX box, [...] > Can someone either identify what is missing above, or give > me some ideas on what else to check? Other idea: AIX by default arrogantly runs writesrv listening on port 2401, though it sounds like you already fixed that... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to see what files have changed in a branch
Patrick Vicanti wrote: > [...]. Is there a CVS command, utility or process that can tell me > what files have changed in the branch vs. which ones have been untouched and > are the same as the ones in the trunk? Thanks. cvs rdiff -s -r tag_on_the_trunk -r tag_on_the_branch modulename The "-s" makes it print out only the filenames and revision numbers instead of the complete diffs. If you have a tag that marks the origin of your branch, then use that tag for "tag_on_the_trunk" (Can't pass up the opportunity to advertise my patch again) I fyou don't have such a tag, I have a patch that might help: http://www.geocities.com/dotslashstar/branch_patch.html With CVS built with that patch, you can do: cvs rdiff -s -r branch_tag.origin -r tag_on_the_branch modulename (I'm presuming that tag_on_the_branch was created like cvs rtag -r branch_tag tag_on_the_branch modulename ) Hope it helps. -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Updating file versions from 1.x to 2.x
Michael Bailey wrote:
>
> I've been asked to update file versions for all files on a branch to 2.0
> Although I realise this is not the cvs way, would it be A Bad Thing?
>
In short, yes, it's a bad thing in my opinion. it will only cause
confusion without providing any real benefits that are not better
provided by symbolic tags.
> If not, is there an easy way to increment the versions of all files on a
> branch to be 2.0?
>
Not advised, though the manual has this to say, if you are hell-bent on
doing it.
http://www.cvshome.org/docs/manual/cvs_4.html#SEC47
I wrote a patch for CVS which contains (along with a bunch of other stuff)
this change to the cvs.texinfo:
! (@pxref{Tags}).
!
! In fact, let's just go ahead and say right now that you are
! STRONGLY advised against using @samp{cvs commit -r}
! to manually set revision numbers. It is STRONGLY recommended that
! you just allow CVS to assign revision numbers however it likes.
! You should use tags instead of trying to assign some meaning to
! revision numbers.
!
! However, if, with that caution in mind, you still want to set the
numeric revisions, the @samp{-r} option to @code{cvs
commit} can do that. The @samp{-r} option implies the
@samp{-f} option, in the sense that it causes the
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Branching in a branch
David Munt wrote: > I am about to branch from an existing branch. The existing branch > has tags set up to allow merges to and from the trunk and I have > successfully merged changes from the trunk into the branch > several times. The new (sub)branch will, ideally, allow merging to > and from from the existing branch. I would like to know if anyone > has attempted same and if so, what pitfalls, if any, were > encountered. I anticipate that such a setup will require a number of > tags to allow cross-merging from one branch to the other and vice- > versa. I've done it plenty of times, there isn't really any difference that I've noticed about doing branch to branch merges vs. trunk to branch or branch to trunk merges. They all work the same for me. -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
"No space left on device" error during cvs status/update"
I didn't see anybody else actually provide a way out, other than to say that /tmp is full, because it's a memfs, and therefore small. One way out is the "-T" option to cvs, (on the server side) to tell CVS to use a different directory then /tmp for this. See: http://www.cvshome.org/docs/manual/cvs_16.html#SEC117 -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Problem with fresh 1.11.1
> $ ls -laR /tmp/cvs-serv13733/ > /tmp/cvs-serv13733/: > total 5 > drwx-- 4 cvsuser cvsusers 1024 Oct 11 07:31 . > drwxrwxrwt 6 root root 2048 Oct 11 07:31 .. > drwxrwxrwx 2 cvsuser cvsusers 1024 Oct 11 07:31 CVS > drwxrwxrwx 3 cvsuser cvsusers 1024 Oct 11 07:31 wps Looks like /tmp has the "sticky bit" set, (that "t" in "drwxrwxrwt"). I know that for me, "make check" (or was it "make remotecheck"?) won't pass with that bit set. Gets some permission problem at some point... (I forget exactly what goes wrong...) Anyway, you might try "chmod 777 /tmp" and see if that helps. Just an idea. -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: How do I move a branch back to the main trunk without merging?
Derek R. Price wrote: > The only thing my method shouldn't account for is files removed from the > branch > and not the trunk. You should be able to use a diff to get those if you > need to. > Try Steve's method first if you have the A tag or can get it into place. [smc] If you don't have the "A" tag (by which I mean a tag that denotes the point at which the branch forked off from the trunk) you might use this CVS patch http://www.geocities.com/dotslashstar/branch_patch.html and then you would be able to refer to, eg. "BranchX.origin" as a name for the missing "A" tag. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How do I move a branch back to the main trunk without merging?
Logan Wilkins wrote: > I need some help with a simple problem. I'd like to move a branch > back to the main trunk, but I don't want to merge the revisions; I > want to overwrite what's in the main trunk with what's in the branch. > Does anyone know of a way to do that. Thanks in advance, So you have something like this...(this involves merging, but I think it does what you want). /---BranchX / -A-(trunk) Where "A" is the tag denoting the point at which the branch forked off from the trunk. cvs rtag -r BranchX BranchX_to_trunk_10_10_2000 everything cvs rtag trunk_pre_branchX_merge everything cvs co everything cd everything cvs update -d -P -j trunk_pre_branchX_merge -j A (rolls back the trunk to point A) cvs commit cvs rtag trunk_rolled_back_to_point_A everything cvs update -d -P -j A -j BranchX_to_trunk_10_10_2000 (the trunk should be in a state just like "A", so these changes should just go in nicely) cvs commit (This is off the top of my head, so you may try it, but no guarantees.) hope it's some help -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 is now available
Greg Woods wrote: > $ /sbin/ping -v -D -s 1373 208.184.89.19 > PING apache.openave.net (208.184.89.19): 1373 data bytes ^? apache.openave.net PING Statistics > 6 packets transmitted, 0 packets received, 100.0% packet loss > > > $ /sbin/ping -v -s 1373 208.184.89.19 > PING apache.openave.net (208.184.89.19): 1373 data bytes ^? apache.openave.net PING Statistics > 4 packets transmitted, 0 packets received, 100.0% packet loss I once saw a problem _very_ similar to this, years ago... it turned out to be an old DEC FDDI <-> ethernet bridge that didn't handle MTU discovery correctly. The symptom I got was, via NFS, from the ethernet side of the bridge I could cat a file 1372 bytes but not one that was 1373 bytes. (the numbers might not be exact, my memory's not that good, but they were right around there, very close.) We ended up down-tuning the MTU on the FDDI side to only transmit packets that were small enough so as not to blow the mind of the bridge. (Don't remember the specifics, not that they'd apply anyway.) Sounds like you might be having a similar problem somewhere along the way. -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs 1.11 on unixware 2.1.2 pserver problems
Hmm, just built cvs 1.11 on unixware2.1.2, running pserver, with unixware 7 and Openserver 5 clients running cvs 1.11 With a 1.10.8 pserver on unixware 2.1.2, the 1.11 clients work fine, but when I try switching over to a unixware 2.1.2 + cvs 1.11 pserver, I get (on the client side) cvs co -c cvs [checkout aborted]: recv() from server mycvsserver: EOF I had some problems with "make check" and "make remotecheck" too, but I attributed them to bad "tr" command..., The bit of code in sanity.sh to find the tr command seemed to hang... but I haven't investigated that too much yet. Anybody have any ideas what might be happenning? So for now, I'm using a 1.10.8 pserver with 1.11 clients... --steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [Info-cvs] Sticky tag does not prevent from removing files
I just duplicated this with cvs 1.11. cvs update -A cvs tag sometag cvs update -r sometag rm somefile cvs remove somefile cvs commit -m removed. The net effect is that "sometag" gets removed from "somefile" Is that intentional? Seems like it could be considered a bug to me, the normal way to do that would be cvs tag -d sometag somefile right? -- steve ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Generated files
John Carter wrote: > Alas, this is a bit of a problem. In that there are hundreds of > the @##$! things. And as I have found out, people tend to get a bit lax > about booking files in. (I found out the hard way, by moving from RCS to > CVS and finding nothing worked. People had been too lazy / forgot to book > things in to RCS.) (Perhaps this is altogether too obvious) The way out of this is to institute a process such that things will noticeably break if people fail to check things in. Have the build process (preferably automatically and periodically) do a fresh checkout or export and build from there. You _must_ do this anyway if you are to have any confidence that your CM process isn't hopelessly broken. You can't assume that it's working, you must test it regularly.
Re: CVS Code Freeze and 1.11 Test Release Available
Noel Yap wrote: > It's interesting that none of "cvs edit -c", "cvs edit -f", and "cvs ci -c" made > it into this release even though the patches have been out there for quite some > time (at SourceForge under project RCVS) and many people are already using it. > IMO, these patches are extremely important in that they satisfy most users who > want reserved locks while not making irate those who prefer concurrent > development -- it's the best of both worlds. You aren't surprised, right? Of course this snapshot is just the current contents of the CVS repository, the same thing you'd get if you did an anonymous checkout. I too have a big patch that I'd like to get in there some time. (but I still have a little work I need to do on it, testing-wise, though there are no problems that I know of with the patch.) This talk of a "feature freeze" amuses me somewhat, as it seems to me that CVS has been under a "feature freeze" for quite some time already (witness that people are advised to upgrade to 1.10.8 from 1.10, since pretty much the only changes in that interval are bug-fixes.) The thing I've noticed about CVS development is this: patches like mine and Noel's aren't rejected so much as silently ignored. No comments are forthcoming to indicate what would make them acceptable. So they just sit there. Smaller, bug-fix patches seem to be more likely to be included, but larger feature patches are usually greeted with silence. This is understandable, after all, it's a lot of work to sift through somebody else's patch and try to understand what they're trying to to and make sure that it's not going to break something. And that's ok, after all, if the situation becomes too intolerable, things like Renegade CVS are possible, thanks to the GPL. (though it's not clear to me that RCVS is keeping up with the patches that are getting applied to CVSor are they?) I *am* glad to see a new release is coming though, had one not been forthcoming I was already toying with the idea of doing my own "cvs export -D" (assuming you can do that anonymously) and just unleashing it for anybody who was interested. I'm glad to see that it won't come to that. -- Steve
[off topic] Somewhat interesting discussion over on advogato
There's a discussion over on Advogato about version control systems, wishlists for CVS or other such systems, etc. that some of you may find interesting. Apparently Karl Fogel is working with some other folks on something called "Subversion"... Anyway,. here' s the URL. http://www.advogato.org/article/145.html -- steve
RE: Re: Finding the date a branch was made
I wrote:
> Chris Deever wrote:
>
> > Is there a way to check out a branch such that CVS retrieves the branch
> as
> > it was before any new changes were committed to it?
[...]
> I have a patch to CVS that might help do what you want.
>
> It's at http://www.geocities.com/dotslashstar/branch_patch.html
>
[...]
> There might be one hitch though, I can't remember for sure.
> (I have to try this tonight to find out for sure).
>
> The patch works by trying to find the first revision of each file on the
> branch.
> So if a branch is created, then files are added to the branch, those added
> files
> are counted as being part of the "origin" of the branch regardless of
> _when_
> they were added. However, I do seem to remember that when adding files to
> a branch,
> a dead revision is added to the branch first, in which case this would
> work
> correctly, and my fears are unfounded.
[smc]
If I would read my own patch, I would see this:
+
+ Note: @samp{.trunk.origin} behaves slightly
+ differently than @same{branchtag.origin} in that, for the trunk,
there
+ is no definitely tagged starting point. Strictly speaking, one
might
+ consider the trunk to be "created" at the time the repository is
+ initialized, and thus logically @samp{.trunk.origin} should refer
to the
+ empty set. As it stands @samp{.trunk.origin} simply refers to the
earliest
+ revisions found on the trunk. This means that, as time
progresses,
+ @samp{.trunk.origin} will generally include more and more files,
as such
+ files are added to the trunk. Note, this does NOT include files
which
+ are added to the trunk via a merge, since a merge will first
create
+ a dead revision on the trunk. It does however include files which
are
+ simply "cvs added" to the trunk. For branches, since there is a
definite
+ tagged starting point for the branch, files which are "cvs added"
to the
+ branch are not referenced by @samp{branchtag.origin}.
+
which makes me beleive I already thought of this and that it does
in fact behave correctly.
Re: Finding the date a branch was made
Chris Deever wrote: > Is there a way to check out a branch such that CVS retrieves the branch as > it was before any new changes were committed to it? Alternatively, is there > a way to determine the date on which a branch was created? I have tags from > the same time period that the branch was created, so also if it is possible > to find the date that a branch was created, I could use a tag from the main > trunk to get the same info. > > Basically, I would like create a list of all log comments of all changes > that were committed to the main trunk since the time the branch was created, > so that I can double check that all changes made in the trunk are properly > applied/merged to the branch. I have a patch to CVS that might help do what you want. It's at http://www.geocities.com/dotslashstar/branch_patch.html It applies to the latest development version of CVS as of 7/9/2000. (Haven't tried it lately though.) With this patch, you can use a tag like "branchname.origin" to mean the start of a branch. so you could do: cvs rdiff -u -r branchname.origin -r branchname modulename to get all the diffs made to the branch. There might be one hitch though, I can't remember for sure. (I have to try this tonight to find out for sure). The patch works by trying to find the first revision of each file on the branch. So if a branch is created, then files are added to the branch, those added files are counted as being part of the "origin" of the branch regardless of _when_ they were added. However, I do seem to remember that when adding files to a branch, a dead revision is added to the branch first, in which case this would work correctly, and my fears are unfounded. I just mention it so you can watch out for it. I think the problem really occurs only when you use ".trunk.origin", because when you add files to the trunk, a dead revision is not added first... (and by this symptom, I begin to think that ".trunk.origin" is somewhat nonsensical anyway, or logically should always be the empty set or something.) Let me know if you find any problems with my patch. -- steve
Unidentified subject!
matt wrote: > >If I do a "cvs checkout -r tagname" and then a "cvs tag -b >branchname" will this create a branch from the tag? > Yes. Also, you can skip the checkout step by using "rtag" if you have a module defined for what it is that you want to tag. cvs rtag -b -r tagname branchname modulename
Re: WinCVS and the info-cvs mailing list
Win32 M$ wrote: > Dear Laine Stump, > >> Oddly, http://www.wincvs.org points people at this mailing list (the CVS >> mailing list) when they have questions about WinCVS. I'm not sure why >> they haven't setup their own mailing list, as other frontends, such as >> tkCVS, have. It would seem to make *a lot* of sense to do so... > [...] > > So: > 1. It says "subscribe", it doesn't say "post the questions about > WinCvs there". I guess the idea is to let the people to 'read' some > posts to learn about the CVS etc. Also, most of the question about > WinCvs actually IS a questions about CVS. The problem with > locking IS A CVS PROBLEM, we wouldn't have to change a single > line of WinCvs/MacCvs code to make locking working properly, > the CVS itself screwed it up and it should be fixed this way or > another IN THE CVS. You're right about this. If someone were to (try to) "fix" locking (whatever that means) then they'd have to make changes to the CVS server. So this could be seen as a CVS question as opposed to a WinCVS question. Supposing somebody wrote a patch to do this, what do you think the chances are that it would get checked in? Probably not very good. There is one camp violenltly opposed to locks. I think I'm more in that camp than the other camp, though I can see there are situations where the concurrent model doesn't work. (unmergeable files).. It's true that CVS *is* explicitly designed to work without locking and this is one of it's major advantages, and might even be essenitial that locks be absent. In other words (without having thought about it too hard) I'm saying it might not even be _possible_ to add locking to CVS without breaking some part of it in a horrible way. (e.g. large scale merging might become an impossible nightmare with locks held on various branches.) Then again there might be some way to do it that's not too obtrusive. (Maybe clearcase has all this already figured out, I don't know...) And, there's Noel Yap's patch to CVS, which I'm not really all that familiar with, but as I understand it, it helps keep people from editing non-mergeable files simultaneously, which is I think, all that people really want from locks. (I think you can get it at sourceforge in the Renegade CVS project.) Of course the other danger with adding locking to CVS is that all the newbies will just automatically use locking for EVERYTHING, and fail to even know about the concurrent model. This may be another reason the original post was greeted with a few less than helpful replies. No reason was given why locking was needed in the first place. When a new WinCVS user comes in asking about locking, it's easy to assume it's because they don't know what they're doing and they think they need locking when they really don't, whether such an assumption is justified or not. (and in the unlikely case you (the original poster) *haven't* tried non-locking systems you *really* should try the non-locking method, you'll never go back.) But back to the topic. I personally don't mind folks posting WinCVS questions here, but it would be nice if "WinCVS" is in the subject line someplace. We're seeing more and more WinCVS users as CVS becomes more popular and more Windows folks start using it. That's fine with me. but I don't own the list, and it might not be a bad idea to create a list (or a newsgroup) especially for WinCVS questions. (Sorry about adding to the flamefest) -- steve
Re: CVS IP Binding Revisited
Robert Sfeir wrote: > Toyed around with this thing. Forgot the name of the > gentleman who tried to help. I added the 10.0.0.172: > cvspserver to the machine and it doesn't work. So > here are my questions: > Can this IP be an aliased IP or does it have to be > bound to another ethernet card? > If it can be an aliased IP, what operating system > were you running that allowed you to add the ip: > server format. No matter what I use it on, it seems > to lock up CVS or FTP or what ever else I use it on, > so something is telling me that I'm not supposed > to be able to do this with my OS. You need to be more specific and more precise in your questions, I'm afraid. It looks like you're editing either /etc/hosts and trying to put in an IP address for some host name "cvspserver" (sounds like the wrong thing to do), or edit /etc/services and put an IP address in there. (Definitely wrong.) /etc/services contains the _port_ number, not the IP address. It's not clear what you are trying to do, but, some IP basics: Processes do not have IP addresses, the network interfaces of the hosts the processes run on have IP addresses. A process may use one (or more) of the network interfaces combined with a port number and protocol (TCP or UDP typcially) and this tuple is what is used to address the process for purposes of network communication. (roughly speaking). So, maybe if you could be a bit more detailed about what it is you're trying to accomplish and what precisely you have tried, and the precise results (messages, etc.) you're getting. you might get some better help. It sounds like _maybe_ what you're trying to do is get CVS to listen for connections coming in on only one network interface while ignoring another, but that's pure speculation on my part. (and besides I'm not sure how to do it anyway.) Normally inetd will listen for connections on all interfaces, I think.
Re: CVS support for /cvs rm -rf/???
> > Shawn Anderson writes: > >... trying to figure out the best way to transport full directory > > hierarchies into the Attic. > > There's a very easy way: > > cvs co directory_to_remove > cvs rm -f directory_to_remove > > > >
Re: CVS support for /cvs rm -rf/???
> Shawn Anderson writes: >... trying to figure out the best way to transport full directory > hierarchies into the Attic. There's a very easy way: cvs co directory_to_remove cvs rm -f directory_to_remove
Re: Anonymous CVS access to cvs.cyclic.com working?
Larry Jones wrote: > Stephen Cameron writes: >> >> Is the CVS server at cvs.cyclic.com still accepting >> anonymous connections? It was a few days ago, I'm sure. > > It seems to have quit accepting connections of any kind > sometime yesterday afternoon. I presume it's being moved > from SourceGear to OpenAvenue, but I don't know that for > sure. If it is, it sure would have been nice if we'd been given >at least a little advance notice. I saw this message (below) on deja.com from Jason Williams, dated 6/30/2000, so I guess they did give notice. [EMAIL PROTECTED] mailing list seems rather unreliable lately. I didn't see that message on egroups.com. And I quit getting mail from info-cvs altogether at my subscribed [EMAIL PROTECTED] account. (although that could be Compaq's doing, not sure.) Also, I posted a couple patches to sanity.sh awhile back and I never saw them show up on egroups.com or deja.com but I know that at least one person (Pavel Roskin) got them. Has anyone else noticed info-cvs behaving like this? (over the last month or so?) anyway here's the message from Jason Williams at Openavenue, dated 6/30/2000 > > In our role as the stewards of CVS, OpenAvenue will be moving > the official CVS development repository as of Wednesday 5 July > 2000. The setup will be the same as on the Cyclic Software > server. It will be set up with pserver authentication, anonymous > access, and an identical cvsroot. For example, the CVS repository < can be accessed as anonymouswith guest as the password > and using the following command: > >cvs -d > :pserver:[EMAIL PROTECTED]:/home2/cvsroot login > > We don't foresee any problems with the switch over but < if you experience any difficulties please contact Jason > Williams, [EMAIL PROTECTED] >
Re: Get a list of files committed on a certain date
Veronica Lee wrote: > Does anyone know by any chance how to get a list of files and their > paths committed on a certain date? For instance, in the following > output: > > dir_a/file_a > dir_b/file_b > dir_c/sub_a/file_aa How about something like this: cvs rdiff -s -D 'Jun 29, 2000' -D 'Jun 30, 2000' top_level_module > diffs.txt I think this will only work on the trunk though. Hope it helps. -- steve
Re: Rolling back a branch to a static tag?
[EMAIL PROTECTED] wrote: > I messed up a merge into a branch and need to roll that entire branch back to my premerge tag. > [...] I would do it this way: (Assuming you have a top-level module called "everything" and a pre merge tag called "pre_merge_tag" and your branch tag is called "branchtag", substitute as appropriate.) cvs checkout -r branchtag everything cd everything cvs tag post_bad_merge everything # this next is the magic command to roll back cvs update -j post_bad_merge -j pre_merge_tag everything There really shouldn't be any conflicts at all. If you're paranoid: cvs diff -r pre_merge_tag (should get no diffs, or perhaps RCS keyword induced diffs at most.) cvs commit -m 'rolled back to pre_merge_tag' (If you get failed up to date check, that means somebody's committed something while you're trying to merge, you want to prevent them from doing that.) Hope it helps. -- steve
RE ".trunk" patch refinement
David Thornley wrote: [...] > .main.latest > types easy too. (. is in the central part of the three basic rows > of the QWERTY keyboard, and doesn't require a shift key.) ".main" is fine by me. [...Regarding support for redundant ".latest" suffix for branch tags.] >And similarity with the main trunk. There's no great harm in synonyms. Except people have to write the code to support them, spend the effort to understand that code when debugging, maintain that code, test that code. If it doesn't add significant value, why put it in? synonyms like this don't add real value, IMHO [...] >JohnC> Its nice to be able to easily figure out where your branch sprouted from >JohnC> using an abstract mechanism. >> >Or an explicit tag. Yeah, I already started working on this a little bit, but I'm not 100% sure my approach is sound yet. > One thing that everybody says is to tag the base of any branch being > cut. Any more or less mechanical thing that lots of people say should > always be done is a prime candidate for automation. It's clear that the revision numbers for the "origin" of a branch tag can be calculated, so it might be better to calculate them rather than automatically put a tag in so as not to store redundant information that could get out of sync. That's the approach I'm taking, calculate those revisions as needed rather than tag automatically. This also means it will work with existing repositoires. [] > I may be slow today, but I don't see how merging the metadata is going > to accomplish all this [stuff that vendor branches do]. And how did merging (meta)data get into this thread? I'm not signing up for _that_, no matter how many people refuse to change the subject line. ;-) Wy too hard, and I'm not really sure I even like the idea anyway. -- steve
".base" proposal (was RE: ".trunk" patch refinement)
(I think the subject line no longer applies) Greg Woods wrote: > (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.) I don't understand what you mean. By "create it" do you mean create some actual "x.base" tags in the RCS files? I know, that given only a revision number, that revision may be on multiple branches and each of those branches might have a different ".base", so computing ".base" given only a revision number is not in the general case, possible. (hence it is not (always) possible to reconstruct a lost branch tag.) However, given a branch tag name, x, instead of a revision number, then "x.base" may be calculated easily, right? (by using RCS_whatbranch() and then doing what's done at the beginning of RCS_getdatebranch() ) And I think in this case, we'd always have the branch tag..., if I understand John C's proposal right for .base correctly. Alos, I think I mistakenly confused BASE with this ".base"..., as I understand BASE, it refers to the revisions that you originally checked out, whatever they may, without any changes that you've made in your working directory, correct? So If that's correct, then BASE is very different than this "branchname.base" proposal. Maybe we should call it something different, "branchname.fork" or "branchname.origin" or something, (supposing somebody has time to look at doing it. -- steve
RE: ".trunk" patch refinement
Fabrice Lavier > This works : > cvs co -l -rb0808 -D "60 days ago" foo > % cvs -v > Concurrent Versions System (CVS) 1.10 `Halibut' (client/server) [smc] Oh. That was easy. :-) Hmm. I think I was remembering the code in "rtag.c", and "tag.c" which forbids the combination of "-r" and "-D" I forgot "checkout", and "update" too, I think, can do this though.
RE: ".trunk" patch refinement
I wrote: > Also, though it might be nice to have a consistent > vision for where we would like things to go, I don't > think all these things necessarily need to be done > at the same time. Actually the next thing I'd like to see would be the ability to specify -r branch and -D date options simultaneously, that seems to me like a big hole that needs to be filled more urgently than those things John C. mentioned. There's already code in rcs.c, specifically RCS_getdatebranch(), that might already do the difficult part of this..., but I haven't looked at it very hard, so I don't know if it works the way the name and the comments say it works. -- steve
RE: ".trunk" patch refinement
John Cavanaugh wrote:
> I havent really followed this thread much but when I looked into
> implementing this and reviewed the code. Yikes, the HEAD stuff
> scared the crap out of me in terms of funky things that work and
> dont work.
>
> I applaud the work being done to get us there but I think this
> is one of the points where a significant benefit can be made
> for cvs iff we are a bit more aggressive in terms of breaking
> backwards compatibility. I know people will probably complain
> but I really really think we need to just bite the bullet and
> do this right.
> - Delete the whole concept of the -A option from update/checkout
That would leave a hole around the area of resetting sticky options,
("-kb", "-kk", etc.) though "cvs update -A" might not have been the right
thing to fill that hole in the first place.
> - Name the main trunk "main" or "trunk" and just deal with the
> consequences of people that already have that branch name
Why should we break things when it's not necessary? ".trunk"
isn't so hard to type, you don't even have to hit "shift".
> - Delete the whole concept of HEAD, instead generalize it to something
This I think can agree with.
> really useful and scaleable like
> .latest - For the latest version on a branch
Some crappy code to do this would be approximately something like:
if (tag && strlen(tag) > 7 && strcmp( tag+(strlen(tag)-7, ".latest")
== 0 )
tag[(strlen(tag)-7] = '\0';
ok, that's an oversimplification. but this ".latest" thing doesn't do
anything
that the branch tag by itself doesn't do already, is my point, so I think I
have
to vote against that one.
> .base - For the version where the branch sprouted
I haven't thought about BASE, or what it means, at all, not one whit, so I
haven't yet formed an opinion.
> - Allow importing directly to the main branch,
I think I agree with this, the key word being "allow".
> get rid of the import branch.
I don't agree with this. I'm not experienced with vendor
branches, but from reading what little I have about what's
going on there, there is a definite purpose and method to
the madness, I believe. I don't think they can or should be gotten
rid of. But I'm sure someone more experienced with vendor
branches will pipe up.
Perhaps there's even some reasoning related to vendor
branches which can explain a method to the madness
around "cvs diff" and "HEAD", though nobody has yet
explained it to me.
Also, though it might be nice to have a consistent
vision for where we would like things to go, I don't
think all these things necessarily need to be done
at the same time. Changes to how "cvs import" works
for instance could be done independently from changes
to implement the ".base" thing for instance.
Also, grand plans on this list have a history of going
nowhere. :-)
-- steve
I think this would significantly improve the functionality
of cvs for users. And I think it might help clean up some
other wise narly special case handling in the code.
Unidentified subject!
Michael Richardson wrote:
> I was reading your patch to try and understand why .trunk is needed...
> "Stephen" == Stephen Cameron [EMAIL PROTECTED] writes:
[..].
Stephen> +
Stephen> + CAUTION: the special tag `HEAD' is interpreted by
Stephen> + the `cvs diff' command in a different way than it
[...portion of patch deleted...]
Actually, the latest version of my patch
(which you can get here
http://www.geocities.com/dotslashstar/branch_patch.html )
reads a bit differently in that area now:
+
+ 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
+ a particular file has not had a revision committed to the
+ branch, in which case the head revision of the trunk is
+ taken. This is clearly wrong. You should use either
+ `.trunk' or the branch tag name rather than `HEAD'.
+ (The `.trunk' tag acts as a branch tag name for the trunk.)
+
(And I verified just now that that is in fact how "cvs diff"
behaves. I don't know why it's so hard for me to remember
these precise nature of the weirdness with HEAD. )
> This seems very strange behaviour for diff, and I now understand why
> you might want to diff against .trunk. But why does diff work that way?
Beats me. But there are some strange test cases in sanity.sh with
some bewildering comments involving "cvs diff -r HEAD"...
Like this:
-
# With a branch sticky tag, HEAD is the head of the trunk.
dotest head-br1-setup "${testcvs} -q update -r br1" "[UP] file1"
dotest head-br1-update "${testcvs} -q update -r HEAD -p file1" \
"imported contents
add a line on trunk
add a line on trunk after trunktag"
# But diff thinks that HEAD is "br1". Case (b) from cvs.texinfo.
# Probably people are relying on it.
dotest head-br1-diff "${testcvs} -q diff -c -r HEAD -r br1" ""
# With a nonbranch sticky tag on a branch,
# HEAD is the head of the trunk
dotest head-brtag-setup "${testcvs} -q update -r brtag" "[UP]
file1"
dotest head-brtag-update "${testcvs} -q update -r HEAD -p file1" \
"imported contents
add a line on trunk
add a line on trunk after trunktag"
# CVS 1.9 and older thought that HEAD is "brtag" (this was
# noted as "strange, maybe accidental"). But "br1" makes a
# whole lot more sense
---
Re: Repeatedly merging from branch to trunk
Brian Collins wrote: > Eric Siegerman wrote: [...] >> The Right Thing(TM) would probably be to collapse (ie. "merge and >> forget") the branch and start a new one, rather than doing >> multiple merges from the existing one -- but I'm not quite sure >> how to do this in a context of ongoing bug-fixes to the previous >> release. > I don't think the Right Thing's practical in this situation. > Our plan is to create a patches branch for each release > and tag "service packs" at various points along the branch. > Programmers fixing bugs on the branch will be required to > merge them back to the trunk as they go so that we don't > end up with an enormous merge job when we cut a new > release. In 99% of cases (he said hopefully! ;-) this should > be a simple merge process because the change on the > trunk will be the same as on the branch. Of course, > if there's a better way to do it, I'm open to suggestions ... The Right Thing is probably more along the lines of merging only the part of the branch that hasn't already been merged each time, and don't re-merge the entire branch each time. Do this with tags, something like this, Suppose your branch is called "Branch", and suppose the point at which it forks off from the trunk is tagged (with a non-branch tag) "trunk_Branch_fork" The first merge would go like this: cvs tag -r Branch Branch_merge_1 everything cvs co everything cd everything cvs update -d -P -j trunk_Branch_fork -j Branch_merge_1 (resolve conflicts) cvs commit -m 'merged between tags trunk_Branch_fork and Branch_merge_1 to the trunk" The 2nd merge would go like this: cvs tag -r Branch Branch_merge_2 everything cvs co everything cd everything cvs update -d -P -j Branch_merge_1 -j Branch_merge_2 (resolve conflicts) cvs commit -m 'merged between tags Branch_merge_1 and Branch_merge_2 to the trunk" And so on. That way, you'd avoid ever merging in the same stuff twice. Some people prefer to use a moving tag to mark the last thing that was merged in on the branch rather than a new tag each time. There is one caveat. When you use "cvs update" with two "-j" options, files which are removed between these two tags are removed in the branch (or trunk) you are merging into without possibility of conflict as I remember. This is because CVS does not assume that the first -j represents the common ancestor of the branch your are merging into, (as it might well not be an ancestor, e.g. if you are doing a reverse merge. That is with two -j options, the concept of a common ancestor doesn't make sense. (So, you might want to do the first merge with just one -j option for that reason.) Conflict detection with two -j options may be a little different too, more along the lines of how "patch" rejects hunks since CVS can't know about a common ancestor. (maybe someone more knowledgeable would care to elaborate on that a little?) Hope it helps. -- steve
RE: ".trunk" patch refinement
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
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: ".trunk" patch refinement
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: A branch-tag name for the trunk! maybe. (was RE: diff bug when using HEAD)
I wrote,: > [smc] A patch that creates a pseudo-branch tag ".trunk" > > > > http://www.geocities.com/dotslashstar/branch_patch.html > > The patch is against the current (6/8/2000) development > > version of CVS. [...] I've discovered "cvs log -r .trunk" doesn't work quite > right, it only shows the log entry for the tip revision of the > trunk, > [smc] Here's a patch, on top of the previous patch, that I believe fixes that. *** log.c.1.10.8Fri Jun 9 09:28:31 2000 --- log.c Fri Jun 9 09:34:38 2000 *** *** 232,237 --- 232,239 prl = &(*prl)->next) ; *prl = rl; + if (strcmp(optarg, TAG_TRUNK)==0) + log_data.default_branch = 1; break; case 's': log_parse_list (&log_data.statelist, optarg);
RE: A branch-tag name for the trunk! maybe. (was RE: diff bug when using HEAD)
I wrote: [smc] A patch that creates a pseudo-branch tag ".trunk" > > > > http://www.geocities.com/dotslashstar/branch_patch.html > > The patch is against the current (6/8/2000) development > > version of CVS. > > > [smc] I've been playing around with it a bit this morning, and I've discovered "cvs log -r .trunk" doesn't work quite right, it only shows the log entry for the tip revision of the trunk, which is not the way a branch tag would behave. Everything else I've tried so far seems to work correctly though, including client-server CVS. It will certainly be next week sometime at the earliest that I can look into doing any more work on this though. (I don't seem to be getting any mail from info-cvs lately, so respond to me directly if you want me to see your message. I think I'm going to subscribe from a different address if this doesn't straighten out soon) -- steve
RE: Diff bug when using the HEAD tag?
Martin Roehrig writes: [smc] my words: > > HEAD as described here definitely has some impossible > > or at least meaningless cases: for instance, a sticky, > > non-branch tag (or date or revision) on a file could > > match a revision that is present on multiple branches, > > so which is the "correct" current branch for which the > > tip revision should be found? There's no sensible answer. > > Pardon me if I ask a silly question, but how could a single revision be > present on multiple branches? As far as I understood the revision number > exactly defines where the revision belongs to, doesn't it? [smc] When you first create a branch, no new revision is created, so if you create mulitple branches, it's possible (very likely actually) that at least some of the files won't have changed on either branch and thus the same revision is used on both the branches. It works because a branch tag records a "magic" revision number with an extra zero inserted. So if you create a branch off the trunk with foo at revision 1.7, say, then the branch tag will point to revision 1.7.0.2 of foo (which is non-existent, BTW), and the next branch tag would point to 1.7.0.4. (the ending numbers go up 2 at a time for some reason.) Until a revision was actually committed to those branches, any refrence to the branches would "magically" fetch foo 1.7. If a revision was committed to branch 1.7.0.2, the revision number would be 1.7.2.1 (The zero is removed, and ".1" is added at the end.) At that point there would be a unique revision associated with that branch. (I hope I haven't botched this explanation. The essence is correct, the details (revision numbers) may not be _exactly_ right...) (Hmm, lately I'm not getting any mail from info-cvs...I wonder if that's a mailing list problems, or if somebody here, in their infinite wisdom, has decided to block mail from info-cvs.
RE: Diff bug when using the HEAD tag?
Larry Jones writes; [my words] > > But, does anyone here know how to > > implement either HEAD or TRUNK as > > described here? [ HEAD meaning the tip revision of "the current branch", acting like whatever branch tag[s] are in effect. TRUNK acting like a branch-tag name for the trunk.] > > Nor do I, and I seem to recall some previous discussions that concluded > it was very difficult if not impossible to get right in all cases. > That's what prompted by alternative suggestion. [smc] TRUNK I think should be possible since it doesn't really do anything that "cvs checkout" doesn't do already, though "very difficult" sounds about right to me. HEAD as described here definitely has some impossible or at least meaningless cases: for instance, a sticky, non-branch tag (or date or revision) on a file could match a revision that is present on multiple branches, so which is the "correct" current branch for which the tip revision should be found? There's no sensible answer. I suppose that could be treated as an error and CVS could say, in essence, "you've asked me a nonsense question." for such files. Seems more trouble than it's worth to me though.
RE: Diff bug when using the HEAD tag?
> Martin Roehrig writes: > [...] > > HEAD should then always refer to the latest revision in the branch resp > main > > trunk the current working copy is based on and therefore it should not > be allowed > > in cvs commands that directly work on the repository (like rdiff - don't > know if > > it is already forbidden there). > > Thus you have TRUNK as an analogue to the branch tags (i.e. it always > refers to the > main trunk) and you have HEAD which refers to the latest revision of the > current > "development line" (be it a real branch or be it the main trunk) as > denominated by the > working directory where the cvs command using the HEAD tag is called. [smc] "TRUNK" sounds useful, "HEAD" as described here, less so, since the branch tag may currently be used for that purpose, (though it might be useful for scripts or something that don't want to have to know what the branch tag is, or in the case of some kind of hybrid sandbox with modules from multiple branches (or even multiple repositorires?)) But, does anyone here know how to implement either HEAD or TRUNK as described here? ,, I don't know how. Well, perhaps someone does... But, if not, the other option, making HEAD at least be consistently interpreted by "cvs diff" seems better than the status quo, and that we do know how to do. -- steve
RE: Diff bug when using the HEAD tag?
Martin Roehrig wrote: > Larry Jones schrieb: > > Peter Wolfe writes [about HEAD meaning the head of the current branch > > rather than the HEAD of the trunk for diff]: > > > > > > Hmm ... while that might be the design intent my observations are that > even > > > this is broken: > > > > I think you're right. It looks to me like what's happening is that diff > > only interprets HEAD as the head of the current branch if the file has > > actually been checked in on the branch; if the file has been branched > > but hasn't actually been checked in on the branch, HEAD is interpreted > > as the head of the trunk instead of the branch point. > > To solve the problems and misunderstandings around this subject, what do > you > think about introducing a new built-in tag (say TRUNK) that does the same > for the > main trunk as a branch tag does for the branch (or should do...), namely > always > refer to the latest revision on the main trunk (TRUNK) resp. branch > (branch tag), > consistently in all suitable cvs commands? (I hope my understanding of > branch > tags is correct so far.) [smc] I like this idea, and have suggested this in the past. I have a patch which I believe makes HEAD work right for "cvs diff" and I have also made a patch at one time that introduced TRUNK that worked just like I wanted HEAD to work but didnt disturb the current behavior of HEAD. If anyone is interested in these patches, I can send them.(I'd post them again, but nobody was ever interested before, so I dont' want to waste the time to try to find them unless someone is actually interested.) -- steve
RE: Diff bug when using the HEAD tag?
Peter Wolfe wrote: [...] > Hmm ... while that might be the design intent my observations are that > even > this is broken: > [smc] [ by "this", the behaviour of "cvs diff -r HEAD" is what is meant. ] > pw.notus.1783> cvs -n update > ? .d [bunch of ? files deleted ] > ? ghr_db_test_comp > cvs server: Updating . > pw.notus.1784> cvs diff -r HEAD|egrep diff > cvs server: Diffing . > diff -r1.4 -r1.2 > cvs server: ghr_command.c no longer exists, no comparison available > diff -r1.10 -r1.9 > diff -r1.3 -r1.2 > cvs [diff aborted]: cannot open CVS/Root: Permission denied > [smc] Hmm, this doesn't make sense to me. First off, none of those revisions look to be on branches. Perhaps you checked out with a tag, but not a branch tag? My best guess is you have some sticky non-branch tag on those files that showed diffs, but it's possible there's more going on there. Do a "cvs status" on the files that differ and see if the tag is a branch tag. And what's that "CVS/Root: Permission denied" about? > pw.notus.1785> III > pw.notus.1785> pwd > pw.notus.1785> cvs diff -r b_V3_3_enh [.. no diffs shown...] [smc] Hmm, that is puzzling, I assume b_V3_3_enh is a branch tag, and is the one that was used to do the checkout? My attempts have all behaved as I expected, but maybe I'm just not trying the right things. [...] > If what you are saying is true then the diff -r HEAD should produce no > output - or is it me that is confused? [smc] No, I think that's right, but check to see that you don't have sticky non branch tags lying around. [...]
RE: Diff bug when using the HEAD tag?
Deever, Chris C. wrote: > When comparing a branch agaist the base trunk, I've noticed a scenario > where > WinCVS 1.1b13 (client) and CVS 1.10.6 (server) miss some of the > differences > in the base trunk. In all developement branches, all changes are > comitted. > > When I go to the root directory of the base trunk and diff against the > branch it finds all of the changes. However, when I go the the root > working > directory of the branch and compare it to "HEAD" it finds all but two > changes. [smc] You are aware that "cvs diff" treats HEAD differently than all other CVS commands, right? "cvs diff" treats "HEAD" to mean the head revision of the current branch (what you have checked out), if I recall correctly, while the other commands (notably "cvs update") treat HEAD to mean the head revision of the trunk There's a test case for this in sanity.sh that makes sure it's so. (it may be a feature, not a bug that you're seeing.) I wrote a patch some time ago to make "cvs diff" treat HEAD the same as all the other cvs commands do, which is the only thing that really makes any sense as far as I'm concerned, but, there are other opinions on that topic. I was involved in some talk of investigating making all other commands treat HEAD the way that "cvs diff" does as an alternate, (at the time, I thought it was just a matter of calling "RCS_branch_head" instead of RCS_head, but, that's not really all there is to it because RCS_branch_head takes an extra parameter which cannot be known (in a way that I was able to figure out) in all the places that RCS_head is used. And, it's not clear to me that trying to do that is not nonsensical, (to use the rare triple negative :-) This comes back to a discussion that's flared up on this list occasionally lamenting the fact that there is no such thing as the equivalent of a branch tag for the trunk. (for a time it was thought that you could use "1" for this, if I recall right, last time that came up, it was established that it doesn't work in all cases. And HEAD doesn't really work like a branch tag, not even considering its weirdness with "cvs diff") Anyway, if you search deja.com for subject "Alternate HEAD patch" you'll find my patch, though perhaps not in the most convenient form. That may make HEAD behave as you are expecting it to with "cvs diff" -- steve
RE: O'Reilly Open Source Conference
Noel Yap wrote: > And how about adding (different levels of) security to such a setup? > [smc] For one, a discussion of setting up secure anonymous read-only access would be cool. (I don't think this is thoroughly documented anyplace,) and how to set up cvsweb, that might be cool too. >
RE: checkout question
[smc] Derek Scherger wrote:
[...]
> $ cvs update
> cvs update: Updating
> U file1
>
> $ mv file1.old file1
>
> After which cvs status knows about file1 and considers it modified or up
> to date depending on what was there in the first place.
>
> What about providing an option to checkout/update to enable this to be
> done automatically?
>
> Any comments or suggestions would be greatly appreciated!
[smc] CVS is actiing the way it acts ("move file1, it is in the
way", or whatever
the message is) on purpose. this is because file1 got there by
means other
than CVS, (i.e. you just created it fresh with an editor, or else
you copied it in
from someplace else manually.) It doesn't make sense for CVS to
consider
the file "modified" because it cannot assume that you mean for it to
be a
new version of the _same_ file. It must assume under these
circumstances
that it is a completely _different_ file that happens to have the
same name
as an already existing file. hence the mssage. Now, I have seen
(with older
versions of CVS) the CVS/Entries file get screwed up and CVS get
confused
and think that files that it created were such files. But I haven't
seen that in
a very long time (probably more than 1 year ago was the last time I
saw that,
and even then, I'm not sure the user wasn't doing something screwy,
like
editing CVS/Entries).
RE: CVS Source Repository
Larry Jones wrote: > Since the current repository is still active, you need to handle this > very carefully to ensure that changes don't get lost in the process. > Best would be to get the actual machine containing the repository from > SourceGear (which is what they did when they bought Cyclic). [smc] As one who's paranoid about backups, I wonder what measures are being taken to back up the CVS repository that contains CVS. Even in the event of catastrophe, I'm sure somebody will have a recent checkout of the CVS source, but it's not so clear that all the history (the *,v files) would be preserved in such a case. Just wondering. -- steve
RE: patch to log.c to permit dates to be output in localtime
Larry Jones wrote a brilliant analysis of my flawed algorithm.; [] > No, I mean that the mapping between UTC and local time is very > complicated [...] What you > want is to have the results switch back and forth between standard time > and DST as appropriate. [smc] oh yeah, hadn't thought of that. yuck. > So, I think the conversion has to be done on the client side, since > that's the only place that has sufficient information to do the > conversion correctly. [smc] Yes, agreed. Again, yuck, (parsing the log output). No wonder nobody has solved this correctly.
RE: patch to log.c to permit dates to be output in localtime
At Larry's suggestion, I'm moving this over to info-cvs, from bug-cvs. Larry Jones wrote: > -Original Message- > From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] > Sent: Friday, May 19, 2000 2:02 PM > To: Cameron, Steve > Cc: [EMAIL PROTECTED] > Subject: Re: patch to log.c to permit dates to be output in localtime > > Cameron, Steve writes: > > > > [smc] So I just took a look at it. You seem to specify the > > timezone > > explicitly on the command line..., is there ary portable way > > to say "the local timezone, whatever that might be" > > Yes, "LT" (case insensitive) is interpreted as "local time" (although, > in the client/server case, I think it's the server's local time). > > > Hmm, on unixware 7, $TZ for me is ":US/Central", but on AIX, > > "CST6CDT", > > so that might not really work well depending on the client's > > and server's > > notions of what timezone names are, So, the user must > > know what > > his local timezone is called on the remote server. > > The way -z is currently implemented, you can specify anything for the > timezone that getdate() will take, which need not have anything > whatsoever to do with how the system represents timezones. > > Please note that I'm not trying to imply that the current -z > implementation is good and should be emulated; on the contrary, there > are some things that seem wrong to me: LT should clearly be the client's > local time, not the server's, and there's no way to get Standard Time / > Daylight Saving Time switching for zones other than LT. I'm simply > arguing for consistency. [smc] Of course, I didn't really consider it an argument anyway, just a discussion, I'm just trying to understand how "cvs history -z" currently wroks. . > Correctly doing the conversion on the server side would require passing > all of the timezone information -- including the Daylight Saving Time > rules -- from the client to the server in some kind of portable fashion, > which I currently don't know of any way to do. [smc] By portable fashion, you mean, wihtout doing time_t arithmetic and without assuming time_t's are in seconds, right? So, how about this: (I got some help from [EMAIL PROTECTED] on this) mktime() taks as input a struct tm, which has fields for year, month, day, hour, min, sec, and it assumes localtime. You can convert freely (if not obviously) between a struct tm and a time_t, using mktime to get time_t's and localtime() or gmtime() to get struct tm's. Now, if I choose a constant UTC time carefully, I may find there's one, which when converted into any timezone will not involve any kind of complicated calculalations, (e.g. no leap years, no crossing month boundaries, no crossing year boundaries, etc.) Using this specially chosen date, use mktime to get a time_t, then use localtime and gmtime to get struct tm's for local and UTC. Because the date is specially chosen, only the day, hour, minutes and seconds need to be looked at, all the other usual complications can be ignored. So the number of seconds difference betwen localtime and UTC can be calculated without knowing what a time_t is by looking at the differences between these to struct tm's for this specially chosen date. (this automatically handles daylight savings time too.) Send this number of seconds over to the server as an ascii string. (Now for my next trick.) On the server side, use the date as found in the log entry (for example) and construct a struct tm from it. (trivial) Next just add the number of seconds to tm.tm_sec, According to the\ mktime() man page, the seconds, as input, are not restricted to 0-59. You can just add them all in, even if it's multiple days worth of seconds. Then let mktime do it's thing, and it will magically make the correct time_t.taking that possibly huge (or negatively huge) tm_sec value into account. Then, convert the resulting time_t back to a struct tm, and there's your answer. That's the theory anyway, I haven't tried it. All the time_t arithmetic and hard calendar algorithms are hidden inside mktime(), or else avoided entirely by using a carefully chosen date. How does that sound? -- steve
RE: CVS security: networked filesystems like AFS, client server ,ssh
[smc] Andy Glew wrote: > > However, I agree with Noel about minimizing sysadmin involvement. > Sysadmin should only be required to set up user accounts. > The setup of the CVS project, repository, management of permissions, > etc., none of it should require sysadmin involvement. > This is one of the biggest reasons I am pro-network filesystems > and against servers. [smc] Just wanted to add one thing: At most sites, where some kind of distributed userids and network filesystem is already in place for other reasons besides CVS, it's true that this is the low-admin route. However, at a site like mine, where we have very transient and varied client machines. (e..g. prototype hardware comes in every couple of weeks, gets several OSes installed on in in the course of it's 2 week lifespan, etc.) even a mildly complicated setup is not practical.. (even a distributed passwd file is too much to ask for.) In that case, 1 NFS mount to get to the CVS executable, plus client server CVS so that user-ids don't have to match is the way to go for lowest-possible-admin involvement. (all this on a private network of course, and the CVS _server_ can be as complicated as need be, the main goal is to reduce to zero the admin effort required for all those transient clients.) -- steve
duplicate key... message ???
> I'm getting some weird results from 'cvs rdiff' > > scameron@zuul 1097 $ cvs rdiff -s -r 0.0 -r efs_x36_dev_br abd > cvs server: duplicate key found for `y' > cvs server: Diffing efs/unix/autobuild/abd > File efs/unix/autobuild/abd/Changelog.x30 is new; current revision 1.2 > > What's the "dupilicate key found for 'y'" message? > > I'm guessing it's from ndbm, while looking in the modules > file. > > But, I can edit the modules file, and commit a change > to the modules file, and I get the message about > rebuilding the modules database, but nothing about > any duplicate key, and I don't have a module called "y" > so I'm not sure what the 'y' key is, or why there's more > than one. > > So what does that mean? Is it a bug. (looks like one to > me) > > Is my modules ndbm file(s) corrupt? Can I rebuild the > ndbm files...hmmm, where are the ndbm files? I'm expecting > some files named modules.pag and modules.dir, or something > like that...(all my ndbm experience comes from Sun's yellow > pages, er, NIS I mean). > > > This is with cvs 1.10.7 on both client and server. > > Thanks for any help. > > -- steve > > >
RE: bread in fat_access not found - Error from Redhat 6
> Steve Cowling wrote: > > The following error was scrolled down the screen: > bread in fat_access not found > We are running Redhat version 6 on a PC and it has been running fine > for about 6 months. The latest work done has been to start using CVS > which was installed with the initial installation of Redhat. CVS has > been working fine for about a week. Since the bread error appeared we > are unable to login either at the console or remotely using telnet > from windows. Every time we try to login the "login incorrect" error > appears. We have tried all user names and root. The strange thing is > that we can still use CVS from our Windows machines using WinCVS > 1.0.6 to login and check files in and out. > I'm not 100% curtain that CVS is the problem but the machine was > fine > until we started using it. > Basically we can't login normally at all. > Has any body seen this before? Or know what `bread' is? > Any help or suggestions would be greatly appreciated. > Steve Cowling [smc] First off, I'm no expert, but, bread probably means "Block read", fat_access, might have something to do with reading a DOS/Windows FAT filesystem. I'm guessing that your password file (or the authentication system somewhere) is corrupted. You probably have a separate CVS password file in the repository that's not corrupted, and that's why you can still use CVS. Things that rely on the system authtentication mechanisms (e.g. login, telnet, ftp, etc.) are hosed. (I'm just guessing here.) Is your CVS repository on the same disk as the root filesystem? If so, you may want to take out the disk, mount it on another system, and copy your repository and anything else valuable that you are able to copy over to a new disk before attempting to repair (or reinstall) over what appears to me to be corruption. If you mount the filesystem on another system, it may become obvious what's wrong. (oh, attempts to read /mnt/etc/shadow are greeted by I/O errors or something.) However, I'm no expert, so you may want a 2nd opinion.
RE: duplicate key...message
Larry Jones wrote: [...] : rebuilding the modules database *does* explicitly > check for duplicate keys. So, the problem isn't with the modules file > after all, it's with CVSROOT/val-tags (which I had completely forgotten > about). [...] You can just delete any lines that don't look right ]...] Yep, that did the trick, thanks. -- steve
RE: Renaming branch?
No, that will not work. In fact this will leave you with no branch tag at all since you didn't use "tag -b", and actually in a very bad place, with no way to recover the lost branch tag. Actually, within the confines of CVS, I do not think there is a way to rename a branch tag. (If I'm wrong, sorry Noel, but I wanted to reply before somebody tried this, in case I'm right, since, if I am, the consequences aren't too cool.) i..e for example, cvs rtag -r branch_name new_branch_origin modulename cvs rtag -b -r new_branch_origin new_branch_tag modulename will give you a new branch tag that branches off the old branch, but will not rename the old branch. > I think the way to do this is: > cvs tag -r branch-name tmp-name > cvs tag -r tmp-name new-branch-name > cvs tag -d branch-name [smc] oops branch tag gone, not cool. > cvs tag -d tmp-name > > It may be wise to use something like "branch-BASE" as your tmp-name and > not to > delete it (since you may need it in the future when doing merges). > > If you manually edit the files without creating CVS locks in the repo > directories, you chance losing others' commits during your editing. > > Noel > > > > > [EMAIL PROTECTED] on 05/10/2000 02:34:15 AM > > To: [EMAIL PROTECTED] > cc: (bcc: Noel L Yap) > Subject: Renaming branch? > > > > > Hello, > > In CVC documentation I found out, that it is possible to rename tags. > But I would like to rename branch. > Is it possible at all? And if it is possible, how to do it? > One possible solution could be to search for branch name in whole > repository and then change branch name in every file where it is > mentioned. Is this possible to do without damaging the repository? > > Best regards, > Alain > > > > > > > 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.
RE: question (preference?) about xmalloc
[smc] David Thornley wrote: [...] > If xmalloc is to initialize memory, I'd prefer it to be initialized > to something obviously bad. Jonathan Gilligan had some very good > suggestions. Now, "obviously bad" is system-specific, but it's better > than initializing to a value selected to be innocuous. (Steve Maguire, > in "Writing Solid Code", p. 49, gives some good pointers on selecting > a bad value.) [smc] IBM (and some others) like to use the value 0xDEADBEEF for this purpose. (and you probably thought IBM had no sense of humor.) I suppose on a machine with 4Gb of virtual (or real) memory, this won't always work. (and then there's the 64 bit machines) So I'm not suggesting CVS should use DEADBEEF..
NTP and timestamps, (was: Could timestamps be replaced with MD5?)
Larry Jones wrote: > -Original Message- [smc] [...] > > 4) Automatic NTP correction of the system time (pretty common in the > Unix > > server world). > > (Under Windows 2000 it is possible for all the machines in a given > > domain to periodically > > sync their clocks with the PDC). > > NTP never sets the clock backwards (see 2, above). > [smc] Are you sure? I thought I remembered differently, so I tried to check..., I found RFC 1305...(is that the right one?) From the RFC 1305, "Network Time Protocol (Version 3) Specification, Implementation and Analysis": "[...] In practice, the necessity to perform a step change is rare and usually occurs when the local host or reference source is rebooted, for example. This is fortunate, since step changes can result in the local clock apparently running backward, as well as incorrect delay and offset measurements of the synchronization mechanism itself.[...]" Apparently a step change in the clock is done by NTP if the clock is off as measured against the reference clock by more than "CLOCK.MAX", but I don't know what value CLOCK.MAX has... (seem to remember 128ms, but that seems pretty low.). -- steve
RE: Renegade CVS
Larry Jones writes: > I'm behind a firewall, too, but the point of a firewall is to keep bad > things from happening, not to keep good things from happening. If you > can't get some route through the firewall when you need it, then you > have bigger problems than keeping up-to-date with the CVS sources. [smc] Yes, bigger problems... The company I work for (Compaq) has many tens of thousands of employees I'm a very small cog within a very small cog within a very big machine. Getting CVS punched through the firewall(s) is simply not an option for me. I suspect lots of other folks are in a similar position. > Checking the source out of the repository is far and away the best > method of keeping up -- doing an update takes a *lot* less time than > fetching a whole new copy of the whole thing. [smc] But it's not an option for me. (except at home, through a slow dialup, in which case it is _not_ faster.) > > 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? > > Given that there's an anonymous CVS repository, there doesn't seem to be > much point. [smc] Might we ask, instead of "why?", "why not?". A simple script fired up from cron to do a cvs export then tar then gzip... how hard could it be? Probably harder than I imagine, for one reason or another, but still... > [...]
RE: Tell me more about CVS
Robert Clavelle wrote: "Tell me more about CVS" (along with a relatively massive signature) More than what? More than you ever wanted to know? Try http://www.cvs.com (Heh heh. : Ask a silly question... :) You might try these after you're tired of that one. http://www.cyclic.com and http://www.loria.fr/~molli/cvs-index.html You might also try browsing past posts to this list at (for example) http://www.deja.com -- steve : > >
RE: Disable "cvs tag -F" of branch tags
Oops, I wrote: > Michael Gersten wrote > [...] > > Just a thought, what's wrong with > > > > cvs rtag -r oldtagname newtagname > > > > to rename a regular tag? > [smc] Well, this is already valid syntax, in which "newtagname" is > interpreted as a module name. [smc] Hmm. No it's not either. (It's too early.:-)
RE: Disable "cvs tag -F" of branch tags
Michael Gersten wrote [...] > Just a thought, what's wrong with > > cvs rtag -r oldtagname newtagname > > to rename a regular tag? [smc] Well, this is already valid syntax, in which "newtagname" is interpreted as a module name.
RE: Disable "cvs tag -F" of branch tags
[EMAIL PROTECTED] wrote: > Greetings! > > Our developers will tag their code for builds under test, and when > problems > are fixed, they will move the current tag until the product is shipped and > > the tag is frozen. Occasionally, someone makes the mistake of moving the > branch tag instead of one of the branch's static tags. The problem here > is > that the tag is converted into a static tag. Sometimes it's hard to > recover. > > Maybe this falls under the "yeah, and any idiot who accidently types 'rm > -rf > /usr' should have to accept the price", but it would sure seem like an > easy > fix for CVS to not allow the -F option when the tag is a branch tag. > > What do YOU guys think? [smc] Some time ago, I had made an (admittedly idle) proposal to add a command which might export a tag file that would contain a definition of all the tags and what revisions of what files they referred to. That way, you could do something like this: 1. restore your pre-disaster repository from backups to some new disk space someplace 2. cvs export_tag lost_tag > lost_tag_file 3. go to your real repository 4. cvs import_tag < lost_tag_file Or something along those lines. Of course nothing became of my idle prattlings, as is normally the case when it comes to CVS.
RE: Proposed new aliases, like HEAD
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. But that's a separate, perhaps easier problem.) > I guess if you are bull-headed enough to want to bump your release > numbers (or stuck with a repository that was copied from an old RCS > repository where this was the "right" way of doing things) then you can > always just manually pick the right number to use when creating the > TRUNK tag and indeed if you are insisting on continuing down such a > questionable track you can still move the TRUNK tag every time you bump > the release number. [smc] I'm not bull headed enough to go through the work of manually making and maintaining a TRUNK non-branch tag. Of course I don't _need_ a branch-tag name for the trunk either, I've lived without it for quite some time just fine. I am bull headed enough to want it anyway though. :) and perhaps even bull headed enough to look at the code some...but I think it will be a rather compilcated thing to implement, For right now, I think I've learned enough and said enough on this topic though. -- steve
RE: Proposed new aliases, like HEAD
Greg Woods, CVS guru, wrote: [...] > > If somebody is interested, I can try to make a version of my patch > that > > makes HEAD work as it does for "cvs diff" in all the other cases. I > don't > > think it's very hard. (Hardest part will probably be fixing > sanity.sh...) > > I'd be interested but don't bother to do it just on my account alone -- > I'll be able to to the same when I get some free time too > [smc] Is there anything lost by doing this, that is. is there anything that can be done with the current implementation of HEAD that, were it changed in this way, could not be done in some other way? > > > You don't really want it to be a CVS > > > magic branch tag but rather just the real RCS trunk branch identifier. > > > > [smc] Oh...I thought you meant you had some way to make a name for > > the trunk as I described above. Tagging the trunk, while useful, > isn't as > > ideal, to my mind, as a real branch-tag name that means the trunk. > > But tagging the trunk with its RCS branch identifier (i.e. "1") is > indeed exactly what you need to do if you want to create a symbolic name > to refer to the trunk. You most definitely do not want to try to create > a CVS magic branch tag for the trunk -- that will not work right. [smc] Yes, I know it won't work right... But a regular tag won't do what I want either. So, if you create a TRUNK tag (just a regular tag that points to a bunch of revisions that happen to be at the tip of the trunk _right now_) then I can't do this: cvs co -r TRUNK everything (change some files) cvs commit -m changed some files on the trunk' _That's_ what I want, a tag which behaves like a branch tag, but means the trunk. > Also, I have confirmed that using "1" will work just fine even if > someone has rolled the release number up to 2.x (and 3.x and so on). > [smc] ok cool. Hmm. I jsut tried the following: cvs co -r 1 everything cd everything (edit some files) cvs commit -m 'changed some stuff' And, oh miracle! it worked! I really didn't expect that, since ordinarily, giving revision numbers like that is definitely not akin to giving a branch tag... But hang on a sec. I just tried this: echo >> somefile cvs commit -r 2.0 -m whatever somefile cd someplace else cvs co -r 1 everything cvs status somefile I got revision 1.3 of somefile, not 2.0... So, for "cvs co", -r 1 doesn't appear to work in such a way that it may be used as a kind of branch tag for the trunk. (I won't say that it works wrong, 'cause I don't know how the heck it's supposed to work...) Hmm, I tried this with cvs 1.10.7...not sure about 1.10.8, but I doubt there were changes in this area... -- steve
RE: Proposed new aliases, like HEAD
Greg Woods wrote: [smc] [...] > > > > My view of it was that currently HEAD appears to mean the head > > of the trunk, with the one exception being that "cvs diff" treats it > > differently. So my reasoning was to "fix" that one excetption, is > all. > > The question is how many times have you ever used "HEAD", and how many > times with "cvs diff" and how many times with other commands? [smc] Well, a bug is a bug, whether you ever trip over it or not, 'specially when the bug is easy to fix. > I mostly use it with "cvs diff" and I've been very annoyed when it > doesn't work the same way with "cvs log", > [smc] Ok, then I have just the fix for you, I've posted it before. Either interpretation of HEAD is pretty simple to code, _if I'm right_. Just a matter of calling rcs_head() or rcs_branch_head() for the "HEAD" specific code. Whatever way it's done, it ought to be consistent, the smallest change to make it consistent is to change "cvs diff". Changing all the other usages of HEAD to match how "cvs diff" does it isn't hard either though. But, having it inconsistent is a bug, and even if I don't ever use HEAD I still want the bug fixed. If somebody is interested, I can try to make a version of my patch that makes HEAD work as it does for "cvs diff" in all the other cases. I don't think it's very hard. (Hardest part will probably be fixing sanity.sh...) [...] > Placing special emphasis on the meaning of the trunk makes lots and lots > of sense in SCCS, less sense in RCS, and much less sense in CVS [smc] Yes, you're right. but to make the user interface, more...orthogonal, if that's the right word, it would be nice if the trunk had a name that behaved exactly as a branch tag does, but referred to the trunk. Well, of course this is not what HEAD is, even if it were consistent, since it's not a branch tag and you can't commit to it.What I'm trying to say is if you had a name for the trunk which behaved just like a branch tag, but meant the trunk, then this would lessen the difference between the trunk and branches, and place less emphasis on the meaning of the trunk... The trunk would then be less special in that there would be one less difference between the trunk and other branches, since the trunk would then have a branch-tag name, just like all other branches. You might achieve this _effect_, by a method I've mentioned before, by having a branch you called TRUNK, and just ignoring the real trunk, but, then you run (eventually) into the problem that on branches, it will take more and more time to compute the most recent revisions since the deltas are applied forwards in time, instead of backwareds in time as they are on the trunk...(if that makes sense..) Merging back to the real trunk now and then could alleviate that though, I suppose, but it's extra work that shouldn't be necessary. And I don't know how this would fit in with vendor branches, since I don't use them and haven't studied how they work. But I'm rather off topic, as I don't really know how to implement this, whereas I think I do know how to make HEAD consistent at least. [...] > > > Having a symbolic name for "TRUNK" > > > isn't necessarily a bad thing, but it does crowd the tag namespace > > > unnecessarily. If you really want to use it then why not just > manually > > > add a real "TRUNK" tag and be done with it? > > > > [smc] How do you do that? [...] > You don't really want it to be a CVS > magic branch tag but rather just the real RCS trunk branch identifier. [smc] Oh...I thought you meant you had some way to make a name for the trunk as I described above. Tagging the trunk, while useful, isn't as ideal, to my mind, as a real branch-tag name that means the trunk.
RE: Proposed new aliases, like HEAD
Greg woods wrote: [...] > My preference would be to do what is effectively the opposite of what > Steve Cameron's proposed patch does. > > I.e make "HEAD" always refer to the head of the current branch > (or the trunk if there is no sticky branch in effect; or if no branch > name is given with '-r') > I can see how that interpretation of HEAD could be useful, so that scrpts may operate on arbitrary branches without having to know what branch they are on, or in a sandbox containing modules from different branches. (if that's not using CVS "incorrectly" :) My view of it was that currently HEAD appears to mean the head of the trunk, with the one exception being that "cvs diff" treats it differently. So my reasoning was to "fix" that one excetption, is all. > and make "BASE" always refer to the base of > the current branch (or the trunk if there is no branch in effect). > > There is no real need for "TRUNK" -- it is the same as specifying "1". > (And of course the base of the trunk is always "1.1", not that this > matters in day-to-day normal usage.) [smc] Ah, I forgot about that, I never use revision numbers, so this always slips my mind. Does this work in all cases, even when you have RCS files that came from someplace else (e.g. just plain RCS)? (I think maybe I asked this before, & I think maybe the answer is "yes", but I wonder how it works, if it does...my gut feeling is to think it won't work... and of course it's too hard to just try it... :) Maybe a little later... > Having a symbolic name for "TRUNK" > isn't necessarily a bad thing, but it does crowd the tag namespace > unnecessarily. If you really want to use it then why not just manually > add a real "TRUNK" tag and be done with it? [smc] How do you do that? [smc] I'm pretty sure cvs rtag -b -r 1 TRUNK everything won't work... right? It will create a branch that's called TRUNK, but it won't _be_ the trunk.
RE: Proposed new aliases, like HEAD
[...] > > Yes, CVS doesn't record a new version [on a new branch] if you don't [ commit any change] . That's annoying. [...] > Well, you can determine full branching order for any branch creations the > file > was included in, due to the tags, so I'm not quite sure why not creating a > new > revision on a branch until you commit changes is a problem, but you're > right > about the rest of it. [smc] Another advantage of doing things this way is that you can do something like cvs rdiff -s -r branch1 -r branch2 everything and have some hope of seeing a list of files which differ, tather than just a list of every file in the repository. -- steve
RE: Proposed new aliases, like HEAD
Michael Gersten > > You're right. For consistency's sake, "cvs up -C file" should get a > clean copy > > of the HEAD. I think, in general, there should be a way to specify the > base > > revision (is there a BASE alias similar to HEAD?) > > Ok, since HEAD means different things, etc, I'd like to propose the > following alias tags: [smc] BTW, there is a similar proposal in cvs.texinfo, but using different names, names that begin with ".", so as to be guaranteed not to conflict with exiting tags...but this might be more difficult to implement. > TRUNK - top of the trunk [smc] I may have a patch that does exactly this. I say "may", because I haven't done extensive testing, and I implemented it by copying the code for HEAD, but fixing the part where HEAD differed for "cvs diff". So if HEAD is broken in other ways besides the "cvs diff" case, then my TRUNK patch would be broken in the same ways. However, I do not know that it is broken. > BHEAD - head of the current branch (or trunk if not on a branch) > PHEAD - head of the parent branch (or trunk if the file split from the > trunk) > [smc] possible? (see comments under SPLIT...) > TBASE - point at which this file left the trunk. Same as self if not on a > branch. > (Essentially, base back at the trunk) > SPLIT - point at which this file left was branched. Same as self if not on > a branch. > (Essentially, base of this branch). [smc] Is this possible? When I create a branch, I always do something like this.. cvs rtag branch_origin everything or cvs rtag -r some_branch_tag branch_origin everything cvs rtag -b -r branch_origin branch_tag everything. I once tried to figure out an algorithm for coming up with the revisions that made up "branch_origin" in case I forgot to create this tag, using only "branch_tag". I convinced myself that it couldn't be done...(well as soon as you say something like that someone will figure out how to do it.) Anyway, this SPLIT seems like the same problem, so I'm wondering if it's possible. I forget now how I convinced myself finding a lost branch_origin type tag was not possible in all cases... Something to do with the fact that CVS doesn't actually create a new revision at the time a branch is created, but only when changes are committed to that branch. [...] -- steve
RE: cvs up -C bug(s)
Noel Yap wrote: [smc] [...] > >I think (maybe) you just want > >to use "RCS_branch_head()" instead > >of "RCS_head()" in the code for "cvs up -C" similar > >to what "cvs diff" does in the HEAD case. > > Yes, you're right. I wasn't really aware of this meaning of HEAD since I > don't > really use it and I haven't used branches in a while. As a request, maybe > CVS > should support syntax like "-r 1.2.HEAD" and "-r 1.2.BASE"? [smc] I don't use HEAD much either, since I work almost exclusively on branches, so don't put that in there on my account. And anyway, why -r "1.2.HEAD?" if you're meaning the head revision of the branch, the branch tag should suffice, right? I'm not sure what "-r 1.2 BASE" would mean I didn't know what "base rev" meant in your earlier post, so I didn't reply to that part...So what does "base rev" mean to you? -- steve
RE: cvs up -C bug(s)
Noel Yap wrote: [smc] [...] > > > >Are you sure about ''? From what I've seen so far, -C means > 'clean > >copy'. (it's not on my 1.10.5 copy, gotta upgrade). > > > >By '', do you mean the revision last checked out, or the > current > >revision for the current sticky tag? > > You're right. For consistency's sake, "cvs up -C file" should get a clean > copy > of the HEAD. [smc] If you mean for "cvs up -C file" to be more or less similar to mv file somewhere_else cvs up -p file > file Then HEAD is probably not what you want... HEAD means head revision of the trunk, (except to "cvs diff") AFAIK. If you're working on a branch, HEAD isn't right.. I think (maybe) you just want to use "RCS_branch_head()" instead of "RCS_head()" in the code for "cvs up -C" similar to what "cvs diff" does in the HEAD case. [...]
RE: simple question (about HEAD)
Dave Makower wrote: > This information is documented, but I want to make sure I am correct > in my understanding of it. > > Is it true that when used with the -r option, 'HEAD' always refers to > the latest revision on the _main_ _trunk_, or does it refer to the > latest revision of the file, including revisions that are on > branches? If the former, then this suits my purposes. If the > latter, then what is the best way to refer to the latest revision of > all files on the main trunk? [smc] "cvs diff" apparently takes "HEAD" to mean the head revision of the branch if there is a branch sticky tag. according to comments and test cases in sanity.sh. and also apparently people are depending on this strange behavior, according to those same comments. (I don't really believe it though.) Other commands treat HEAD to mean the head revision of the trunk, AFAIK. I have a patch which makes "cvs diff" work like the other commands wrt HEAD, though I haven't tested it extensively. If anyone is interested (seems unlikely :) I can send it again. -- steve
RE: Build systems
[EMAIL PROTECTED] wrote: > My curiosity is piqued by several posts recently on the subject of > builds. [smc] [...] > For those of you that do run builds of your products/systems where cvs > is the underlying version control system, how many of you: > > 1. Run them (let's say nightly or frequently at any rate) out of a > sandbox that has been massaged until there are no modified or ? files in > it > 2. Run them using make and VPATH [smc] [...] > 3. Do (2) but do a cvs -export to a fresh area first > [smc] [...] I guess we do closest to #1, I guess. The builds are run periodically and automatically. We do a fresh "cvs rtag" + "cvs checkout" rather than an export... But not for any real reason. (though the build scripts look once in one of the "CVS" directories to get the tag, but that's not a real reason, as it could be (shoudl be) done other ways. We also build on multiple platforms. We handle that in the simplest way possible, by doing multiple checkouts. -- steve >
RE: Writing shell scripts that use CVS / Automatic checkout
You only need to "cvs login" one time. After that it is not necessary, The information is stored in ~/.cvspass If your cron job is using different CVSROOT values for each time it is run (seems unlikely) then you'd have to log in of the CVSROOT values once. (presumably there is a small, finite, predetermined set of CVSROOT values you'd be using, (probably just one value)... Well if not, you're doing something rather strange...:-) hope it helps --steve > -Original Message- > From: Mikael Grave [SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, March 14, 2000 8:18 AM > To: cvs-list > Subject: Writing shell scripts that use CVS / Automatic checkout > > Hello, > > I am currently writing a small Shell script that will log into my CVS > respository and will issue a checkout. This script is intended to be > called every 10mn by a crontab. > > Since "cvs login" does not have a command line option to pass the > password, I was wondering if there is a simple trick to run "cvs login" > automatically? I have tried things like: > > echo "x" | cvs login > > But it does not work (the password is not taken from the buffered stdin > I guess). > > My original purpose was to perform an automatic checkout (in a test bed) > every time someone was doing a commit. Doing this with "commitinfo" did > not seem possible since "cvs commit" recursively commit all modified > files, if 100 files are commited at once, I don't want commitinfo to > launch 100 checkouts (maybe should I simply run one "update" per > "committed" file?). So I decided to go for a crontab (not as good, user > may have to wait 10mn to see their changes published in the test bed). > > Any help or trick are welcome. I guess my problem is quite common. Hope > my questions are not too stupid :) > > Cordially, > > Mikael > -- > Mikael Grave Tel. (613) 731-4046 http://www.webmotion.com > Webmotion Inc. Fax. (613) 260-9545[EMAIL PROTECTED] > `'
RE: WinCVS: merge by substitution
> Is there a clean way to merge from a branch in such a way that the > resulting > merged file is exactly the same file that was on top of the branch when > the > merge command is issued ? [smc] You mean copy the files on the branch onto the trunk, throwing away any changes made on the trunk since the branch was created? One way: cvs rtag trunk_right_now everything cvs rtag -r branch_tag branch_right_now everything cvs co everything cd everything cvs update -d -P -j trunk_right_now -j branch_right_now Then take a good hard look to be sure that's what you wanted before comitting. Hope it helps. -- steve >
RE: cvs tag vs. rtag
Laird Nelson wrote: > Can someone give me a pointer on when to use cvs tag vs. when to use cvs > rtag? I know, for example, that cvs tag doesn't show up in the history > file, and that cvs rtag requires you? I think? to feed it the revision > number of whatever you're tagging, thus preventing you from saying "cvs > rtag the tree the way it is now". What common situations is each > command used in? > [smc] One big difference between "cvs tag" and "cvs rtag" is that "cvs tag" requires you to do a "cvs checkout" first, while "cvs rtag" does not (which is why it requires you to feed it the revision number (or another tag.) I use "cvs rtag" to tag builds prior to checking them out, because I have to check them out on multiple architectures... As for not being able to say "cvs rtag the tree the way it is now"... Well if, by "the tree", you mean your working directory, yes this is true. If you mean by "the tree" the current state of a branch... cvs rtag -r branch_tag my_new_tag everythign Or for the trunk... cvs rtag -r HEAD my_new_tag everything hmm. "HEAD" scares me a bit, I'm not sure how well it really works. I don't use the trunk much, so I don't use the HEAD pseudo-tag much. I do know that "cvs diff" treats HEAD differently than everything else... Hope it helps. -- steve
RE: problems with checkout (on LINUX)
Eric Hernandez wrote > Hello, > > I have a repository set up as: /xxx/src/master > The contents look like this (using 'ls'): CVSROOT Scripts ccvs > As user Joeshmoe, I execute the command 'cvs checkout ccvs' which > results in > cvs checkout:Updating ccvs > U file1 > U file2 [smc] Question: What is your current directory when you issue the "cvs checkout" command? Are you sitting in /xxx/src/master? If so, that is your mistake. You _never_ work inside the repository. It's not like sccs or RCS in that regard. (I'm only guessing at what your trouble may be, if what I'm saying is obvious, to you, well then, I'm sorry to waste your time. --steve > . >
RE: Feature wanted: patch support and moving in the tree
[smc] [snip] [smc] [..regarding "cvs update -j rev1 -j rev2 myfile.c" ] > > > > rev1 and rev2 can be arbitrary revisions. (Well, with the > > restriction > > that they must already be in the same repository...which is > > the main difference I see from the proposed "cvs patch". > > That, plus that 'cvs patch' permits any tool to create patch files. > I could, for example, get a diff from another source code system, or from > another user elsewhere. Might not even be based on the same file. [smc] Hmm it seems to me then, just use patch. I'm no expert on patch though, perhaps it has inadequacies that make it unsuitable. [snip] > (Incidentally, does update -j -j work if the two revisions are not on > related > branches? [smc] the two revisions may be any arbitrary revisions, just as you can feed any arbitrary patch into the patch program, doesn't mean it will work nicely. > What if there is a conflict between the two revisions, as well as a > conflict in > your own code in applying this? (all three versions do different things to > one > area).) [smc]There can't be a "conflict between the two revisions." > You have to have at least 3 revisions before a conflict is possible...so I'm not sure what you mean. When you do "cvs update -j rev1 -j rev2 myfile.c", it is very much like (identical to?) doing diff -c myfile.c.rev1 myfile.c.rev2 | patch myfile.c > > [smc] [snip] > > Now, if 'branch2' (the new) is a descendant of 'branch1' (the old), and I > want > a script to automatically go up one level of branching, how do I do that? [smc] Sorry, I don't know what you mean by "go up one level of branching" > cvs update -A removes all branches, back to the trunk. [smc] Hmm. I never use "-A", I always work on branches, so I never use the trunk, except when merging to the trunk for the purpose of creating a new branch.. so I'm afraid I can't help much there. > How do I say 'Look in CVS/Tag, find the place where this branch came from, > and go to that branch or trunk'? [smc] "place where this branch came from?" I think you mean what branch did this branch branch off of? Which might be different on a file-by-file basis... (a pathological case, to be sure.) I don't think you can do that. Or know why you'd want to... what are you trying to accomplish? > And, my first question is still there: if I have some files that are > modified, > and I do a 'cvs update -r new-revision', I'll move over to new revision; > if > files are modified, then any changes will get merged in. > > How do I say 'only permit this update -r if my (modified) files are > current for > the new location? (no merge needed) [smc] If I understand correctly... You are working away on some branch, branchA, say, and you want to start working on branchB, but you don't want to blow away mods you have made (but not committed) to your branchA sandbox... is that it? Can't do it, not that way. (I can't think of a way, at least) Hmm. you could do "cvs -nq update" to see what files have been modified, then do "chmod -w" on those files prior to the "cvs update"... I don't know if cvs update would puke and die or just issue warnings for the files it couldn't write. Here's one different way: cvs co -r branchA everything cd everything cvs tag start_of_hacking (hack away on files) cvs commit cvs tag end_of_hacking cd .. rm -fr everything cvs co -r branchB everything cd everything cvs update -d -P -j start_of_hacking -j end_of_hacking This will make the same changes you just made to BranchA on your BranchB sandbox. But that doesn't guarantee the modified files are _the same_ as what they were on BranchA. (why would you want that though? You'd be (potentially) blowing away other's changes on branchB.) Also doesn't guarantee absence of conflicts... so it's probably not what you want. -- steve
RE: devel-cvs@gnu.org
I wrote:
> That list ("devel-cvs") already exists, sort of.
>
> Read the file DEVEL-CVS from the cvs sources.
[smc] And reading this DEVEL-CVS file a bit myself,
now I see this:
"These topics should either go on info-cvs,
or have a new mailing list created for them."
RE: devel-cvs@gnu.org
That list ("devel-cvs") already exists, sort of.
Read the file DEVEL-CVS from the cvs sources.
(it mentions "[EMAIL PROTECTED]"...I don't know
if that still works...)
Essentially anyone may read the messages sent to
devel-cvs but only those who are able to
commit to the CVS repository containng the CVS source
may post messages there, according to DEVEL-CVS
I, for example, subscribe to that list but cannot
post to it. As it happens, there is almost zero
traffic on that list. (or maybe it's broken now since
cyclic is gone?)
-- steve
RE: Feature wanted: checkin time tagging
Tobias Weingartner wrote: > On Tuesday, March 7, Michael Gersten wrote: [smc] [..snip..] > > The current CVS update/commit, without built-in support for flying fish, > > does not support that middle step: track changes to it. > > Ahh, I think you need to look into tags. One place I worked, not > necessarily > the best way of doing it, had a number of tags (not branches), which were > used > to help in this regard. The head of any branch where development was > going > on, there was a tag which was the tag used to build off of. [smc] We do something very similar here, works pretty well for us. [..snip..] > > How about this compromise: A CVS command to walk the local sandbox, find > > all the patch reject files, and mark conflicts properly? (With an option > to > > clean up the patch output files afterwards, perhaps smarts or a switch > to > > remove those patch outputs that were successfully dealt with > already/prior > > run/manually, etc?) > > Nope, this would be better suited in the "patch" binary itself. It is > already > "walking the tree", since it is going after the patch file. It could have > a > "cvs mode" of sorts. Not really the way the patch maintainers are likely > to > do it though... > > > > Or a CVS command to take diff files as input and apply the changes, > marking > > conflicts appropriately? > > Hmm, this one has some merit. We do have a "diff" tool within CVS, so why > not a "patch" tool. I'd veto it on the grounds of bloat, patch is by no > means > a "small" tool. On the other hand, I'd see it as a way to round out the > support that CVS would/could have for diff/patch... > [smc] Hmmm. Doesn't CVS already contain a significant part of "patch", or something very like it, in order to do merging? Also, you can kind of already do this. e.g. cvs update -j rev1 -j rev2 file_to_be_patched And of course this can extend to the entire repository at one shot. rev1 and rev2 can be arbitrary revisions. (Well, with the restriction that they must already be in the same repository...which is the main difference I see from the proposed "cvs patch". [smc] [..snip..] > > > Ok, what is to prevent you from making a diff of your current changes > (to > > > save them), checkout/update on the branch, merge that to the trunk > > > > Tell me the CVS command to "Merge this up one level". > > > > "cvs update -A" will get me back to the trunk from any level down of > > branching, assuming that nothing is modified. > > What is the flag to update to only go up one level of branching? > > What is the command to move elsewhere on the tree only if it won't cause > a > > conflict, or if it won't cause a merge? > > You can do diffs between pretty much any two revisions of a file. So, if > you > have something that you commited on a branch, between two revisions, and > you > need to move this to the trunk, you can take a diff, and use "patch" to > help > you in the "transplant" of the code. Of course, your milage will vary, > depending on how close the two codebases really are... [smc] Or you can use "cvs update" e.g. suppose I have branch1, and branch2. I want myfile.c to be the same on branch1 as it is on branch2. rm myfile.c cvs update -r branch1 myfile.c cvs update -j branch1 -j branch2 myfile.c # note, you are pretty much guaranteed no conflicts here. cvs commit -m 'now equals branch2 revision.' myfile.c The fact that the trunk is anonymous may give you some trouble here, if you're working on the trunk, but regular tags can help out in that case. However, the thing is most people usually do _not_ want to make one branch _equal_ to another, they want the changes from one branch merged in to another branch. However, if this is what you want you can do it: cvs co -r branch1 entire_repository cd entire_repository cvs rtag -r branch2 branch2_mrg_to_branch1 entire_repository cvs update -d -P -j branch1 -j branch2_mrg_to_branch1 ( make branch1 equal to branch2 ) cvs commit [smc] [...snip...] > > So again, my questions to you are: > > 1. What operations on branches do people really want/need/use? > > To be truthfull, I very rarely use branches. They are rather painfull to > work > with. (The one admission I'll make...) But when they are necessary, then > no > other method really works... [smc] Hmm. Why do you say that? Maybe it's just a matter of practice. We use branches exclusively... (we never commit to the trunk, except when creating a new branch.) There is some tagging maintenance you have to do with branches, and the pitfalls could probably be better documented.: Two of the pitfalls can be avoided this way: 1) Alwa
RE: Enhancement suggestion: CVS rename
Bergur Ragnarsson writes: (and I'm moving this thread over to info-cvs rather than bug-cvs, because it seems more appropriate, to me.) > Hello all, > > I'm using CVS 1.10 and I am quite happy with it; however there is one > very important feature missing: > CVS rename [smc] [...snip...] > To implement rename a name-location fields needs to be added to the > standard revision information (author, date, state, log). This fields > can be added in several ways: > * use an existing fields (i.e. author). > * use special symbol (dirty !?) > * add a new fields in such a way that the currrent rcs parser > would ignore, i.e. not complain about - maybe not possible !? > >> Making the rcs file format backwards incompatible should be > avoided if at all possible. > > Modifications: > > 1. Add name-location field that is associated with every revision (like > author). The location fields would be a path name starting from CVS_ROOT > - it would not include CVS_ROOT path prefix => easy to relocate > repository. > * the location in the latest revision would be in sync with cvs > repository location > * the name in the latest revision would also be the name of the > file in the cvs repository > > 2. cvs checkout: > find revision > check if name-location field exists, if so check file out to > that location and under that name > > 3. cvs rename > insert pending name and location change > > 4. cvs commit > (this should be integrated in rcs) > move the updated file to the new name-location (often no change) > > The design has two important attributes: > * The cvs repository will look the same for the main branch for > this new cvs and the current one. This means that when a user looks at > the repository, he sees the most recent layout - which is natural. > * All information is still stored in one file only. > [smc] It would also have this (undesirable) attribute. suppose I have a repository with two modules, MOD1 and MOD2 which are subdirectories of a directory called EVERYTHING. I can do cvs co EVERYTHING cd EVERYTHING/MOD1 echo whatever > file1 cvs add file1 cvs commit -m 'x' file1 cvs tag tag1 EVERYTHING cd .. mv MOD1/file1 MOD2/file1 cvs rename MOD1/file1 MOD2/file1 cvs commit -m 'moved file1 to MOD2 from MOD1' cd .. rm -fr EVERYTHING cvs co -r tag1 MOD1 ...uh oh! file1 doesn't appear! This is due to your proposed modification #4, above, and to the way that "cvs checkout" is designed. Or did I miss something? For you proposal to work, probably you'd want to store the files in some directory structure which didn't necessarily resemble the layout after a "checkout", since, in this case, "cvs checkout" would have to look inside every file in the repository to determine whether each file was part of the module being checked out at the time the specified tag was in effect. That is, if you just mv the "*,v" files around, you have to rather drastically change how "cvs checkout" works. (and update, & export too, I guess... and "cvs tag" too... tons of stuff it would seem.) -- steve
RE: cvs up -C bug(s)
Noel yap wrote: > "cvs up -C file" doesn't work correctly if "file" has been modified both > in the > repo and the working directory (ie a merge is "needed"). IMO, you should > wind > up with a clean repo copy (ie no merge). The default repo copy should be > the > HEAD [smc] or the tip of the branch if the revision in your sandbox has a sticky branch tag, of course. [...]
RE: scripting CVS login
Art Solano wrote: > Can you script cvs login? I have read through the documentation and it > only seems to be interactive. > [smc] It is AFAIK, always interactive, like telnet. That doesn't mean it can't be scripted, what you might want is "expect", a program made specifically for dealing with (scripting) interactive programs. URL is http://expect.nist.gov/ The other thing, I believe "cvs login" is necessary only once, and the necessary information is retained in the ".cvspass" Subsequent logins are not required. So if your script is always to be run as the same user against the same repository, just log that user in once and forget about "cvs login"... Hope it helps. --steve
RE: "cvs edit -c" patch (Was: CVS File Locking)
Noel Yap wrote, (about his "edit -c" patch [...] > I think it might require server connection when using "cvs edit", > but I haven't tested this (ideally it should only emit a warning but I > haven't > taken the time to find out how to do this (ie test whether or not the > server can > be contacted)). [smc] Can't you just yank out the network cable and see if it works as you would expect/like it to, or if it hangs or complains excessively? That's probably too easy to be the real answer, I suppose esp. if your local machine is super-dependent upon NFS mounts...
RE: CVS server problem on Solaris
> -Original Message- > From: Thomas Wichmann [SMTP:[EMAIL PROTECTED]] > Sent: Sunday, February 27, 2000 5:50 PM > To: [EMAIL PROTECTED] > Subject: CVS server problem on Solaris > > > Moin, moin > > I have a strange problem with "CVS 1.10 `Halibut' (client/server)". > It is a not set CVSROOT variable problem on Solaris 7. > > Everything seems to work fine except remote access from > a different nor the same machine using pserver. > > In /etc/inetd.conf I have > > cvspserver stream tcp nowait root /usr/local/bin/cvs > --allow-root=/data1/cvs pserver [smc] Here is one problem. You need an extra "cvs" in there. Remember, in /etc/inetd.conf, the arguments to the command include argv[0], the name of the command... so: cvspserver stream tcp nowait root /usr/local/bin/cvs cvs --allow-root=/data1/cvs pserver (all on one line, of course, in case my mailer breaks lines.) -- steve > and in /etc/services > > cvspserver 2401/tcp# CVS authentification (by > Wichmann) > > In /data1/cvs/CVSROOT/passwd I have an account for "wichmann". > > That is, what happens: > > bash$ export CVSROOT=:pserver:wichmann@bpdev1-neu:/data1/cvs > bash$ cvs login > (Logging in to wichmann@bpdev1-neu) > CVS password: > cvs [login aborted]: unrecognized auth response from bpdev1-neu: cvs > pserver: No CVSROOT specified! Please use the `-d' option > [smc] Why the botched inetd.conf would give this sympton, I don't konw...maybe there are other problems too. > Ok and tried it different > > > bash$ cvs -d :pserver:wichmann@bpdev1-neu:/data1/cvs login > (Logging in to wichmann@bpdev1-neu) > CVS password: > cvs [login aborted]: unrecognized auth response from bpdev1-neu: cvs > pserver: No CVSROOT specified! Please use the `-d' option > > Looks like the error message is generated from the CVS server > but how can I set a variable for the server part? > > If I try to use CVS locally on the machine everything works as > expected. I have done a similar installation and setup on > Debian 2.1 and have had no problems. > > I don't understand this behavior. > > Can someone help me out of this? > > > Thomas
RE: AIX pserver CVS System password lookup
> Cameron, Steve writes: > > > > So maybe it will work after all, if you run CVS as root. > > (though this surely defeat any security gained by > > keeping passwds in /etc/security/passwd) > > I'm not sure what you mean by that. The idea of shadow passwords is to > keep people who aren't root from being able to read them. Running cvs > as root doesn't defeat that, cvs only runs as root long enough to check > the password, then it switches to running as the user. > [smc] ok, well maybe I shouldn't have said that then...sorry.
RE: CVSROOT/cvsrc
Noel Yap wrote: [...] > If you do come up with a general solution, here's my wishlist: > 1. The global .cvsrc is copied onto the client (assuming client/server CVS > of > course) so that server contact isn't mandated. > 2. By default, user .cvsrc files extend global .cvsrc settings. > 3. There should be a way for users to override global .cvsrc settings. [...] (long as we're wishing...) It seems to me, that since the "global" .cvsrc (being proposed) is global only to a given repository, then it it should be possible to specify local .cvsrc files on a per-CVSROOT basis too. So, for instance, you might override one repository's obnoxious global .cvsrc settings, but accept another repository's wonderful global .cvsrc. -- steve >
RE: AIX pserver CVS System password lookup
It looks like getspnam doesn't exist, but getpwnam() does on aix, and further, according to the man page, getpwnam will look in /etc/security/passwd if the process has privilege to do so.. (is running as root)... So maybe it will work after all, if you run CVS as root. (though this surely defeat any security gained by keeping passwds in /etc/security/passwd) Have you tried to make it work? Maybe I will try it later today. -- steve > -Original Message- > From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, February 22, 2000 9:47 PM > To: [EMAIL PROTECTED] > Subject: AIX pserver CVS System password lookup > > > > Hi! > > I'm using AIX 4.3 and CVS 1.0 with pserver > I do not wish to use the CVSROOT/passwd file (i wanna use the system > /etc/passwd > file). > (CVSROOT/config has SysAuth=yes) > However, the encrypted passwords are not in /etc/passwd . ( they are in > /etc/security/passwd apparently ). > > Is there anyway to make this work? > Is there anyone using pserver with system password lookup on AIX? > > Thanks in advance. > > mind boggles, > aditya >
RE: Unexpected conflicts in branche merges
David Martin wrote: > Sankaranarayanan K V wrote: > > > I am trying to make the HEAD of a branch B1 the same as that of another > > branch B2 by: > > > > cd > > cvs update -j B1 -j B2 > [smc] [...doubts about CVS supporting arbitrary merges snipped...] > > I would think that updating/merging branches which forked from the same > base version might work. However, if the branches forked from different > base versions, I would think there would be problems since a common > ancestor would not necessarily be found. [smc] When you specify two "-j" options, CVS does not try to find a common ancestor. It merely computes the differences between point A and point B in the form of a patch, and attempts to apply that patch. In this case, point A is the tip of one branch, and purportedly also the current up-to-date contents of the sandbox, and point B is the tip of another branch. So CVS should compute the diffs between A and B, and apply those diffs to the sandbox, which is supposed to contain exactly A... so, reasonably one could expect the patch to go through without a hitch (conflict) and produce a sandbox with contents identical to B. This is apparently not happenning in this instance, hence the original question. -- steve
RE: Unexpected conflicts in branche merges
Sankaranarayanan K V wrote: > I am using CVS 1.10.7 on Solaris 2.5.1. > > I am trying to make the HEAD of a branch B1 the same as that of another > branch B2 by: > > cd > cvs update -j B1 -j B2 > > This should NOT give me any conflicts. > > But I do get conflicts in some cases -- I don't know why. [...] What kind of conflicts...? What do they look like? For some file with a conflict, what if you do cvs diff -c -r B1 -r B2 > patchfile patch problem_file < patchfile Does that work as you would expect? -- steve
RE: pserver problems
One solution is this: on AIX look in /etc/services, it has "writesrv" running on port 2401 This is apparently how IBM decided to implement the "write" command which allows users to "write" messages to each other's ttys. Probably nobody uses this command at your site, since pretty much nobody uses this command anywhere. Just get rid of the writesrv process and change /etc/services to give cvs port 2401. There is an entry in /etc/inittab that starts writesrv... Get rid of that too, and kill the writesrv process. (I'm new to AIX, (< 3 weeks) but this is how it appears to me. As for password shadowing...Hmm. not sure. there are no encrypted passwords in my /etc/passwd file, only "!" for every password "man 2 getspnam" comes up empty, and config.cache indicates "configure" couldn't find getspnam() either. And there is no /etc/shadow file. So I don't know where IBM has decided to keep the passwords. So I suspect using system passwords on aix may be broken, but I haven't tried it since I'm only running CVS as a client on aix. Hope it helps some. -- steve > -Original Message- > From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] > Sent: Monday, February 21, 2000 10:04 PM > To: [EMAIL PROTECTED] > Subject: pserver problems > > > > CVSers, > > Hi! Can anyone please provide me with more information about the AIX 2401 > port > patch? > > Will the system password lookup fail if the encrypted password is not kept > in > /etc/passwd (i.e. there is password shadowing)?? > (pserver access; in CVSROOT/config we have SystemAuth = yes). Does AIX > default > to password shadowing? > > > Thanks in advance, > aditya >
RE: removing the need for "cvs add file" to contact the server....
Noel Yap wrote: > Beware of premature optimisation. We've already laid out a process that > relies > on empty directories being created in the repo. IOW, it's *necessary* to > allow > creation of empty directories for this process. It would be a kludge to > create > a dummy file for this purpose. [smc] (ok I'm repeating myself..sorry.) But if you ever decide to use branches Noel, this "kludge" is exactly what you will have to do. And branches are such a major part of CVS, you shouldn't just ignore them just because you don't happen to use them. Because of the way that CVS decides if directories are present or absent on a branch (by checking if there are any files within the directory (or subdirs) that are present on the branch) this means it isn't possible to "fix" it without introducing something extra to keep track of directories...which I'm not sure is a good idea. (and I bet there is at least one person who thinks it is a _terrible_ idea :-) I'd rather see the trunk behave consistently with how branches behave...that is: No empty directories. -- steve
RE: Anonymity of trunk and merges
Sankaranarayanan K V wrote: > On Thu, Feb 17, 2000 at 09:33:03AM -0600, Cameron, Steve wrote: > > > for "cvs diff", HEAD means the head revision of the branch > > sticky tag. > > > > for all other commands, as far as I can tell, it means the head > > revision of the trunk. > > How do I do a "cvs diff" when I need to diff a branch and the HEAD of > the trunk? [smc] You patch the source code to fix it and recompile CVS. Here's a patch (same as I submitted to [EMAIL PROTECTED] some time ago... I have gotten exactly zero feedback, positive or negative, and I didn't do a _whole lot_ ot testing, but I think it works right.) If you try it, and it you find problems, or find that it works great, let me know. -- steve . <> headpatch
RE: branches & merge
Little Green Men ( [EMAIL PROTECTED] ) wrote: > Hello, > I have a little concept question. > what should be the correct way of setting an cvs environment for several > developers ? [smc] How many is several? I will assume < 10. > should we open a separate branch for each developer ? [smc] No, not unless you have some specific requirement that makes this a good thing to do. Ordinarrily, no need for that. > and if so, > what happens after i merge one branch to the trunk ? do i delete the > branch [smc] No, you pretty much _never_ delete branches. When you're done with a branch, you just ignore it from that point on. > and open a new branch > for that developer ? or let him continues to work on that branch (which > i guess will create problems on the second merge [smc] If you were to go the route of creating separate branches for each devveloper, then you'd probably want to make a new branch whenever an old one was merged. But why the need to make branches? Branches have there places, but this doesn't sound like one of them. > because it will merge > things that ware already in the trunk) > and how do i keep truck of all the branches ? [smc] Manually. Write it down. > and final question, if i do decide to remove the branch after merge, [smc] No, don't remove branches, you will only cause yourself pain. Another thing when you create a branch, always use a regular, non-branch tag to mark the origin of the branch, otherwise, you will have no way to refer to this point later, if you need to. (i.e. later, when it is too late to do anything about it.) example, to create a branch cvs tag branch_one_origin everything cvs rtag -b -r branch_one_origin branch_one everything However, you haven't said anything that indicates you need to use branches at all. why not just have everyone commit to the same branch (or to the trunk?) Or is there some specific reason this won't work for you? Hope it helps -- steve [...]
RE: Anonymity of trunk and merges
Sankaranarayanan K V wrote: > Hi, > > (1) How do I refer to the trunk in commands like > > cvs update -j > > cvs diff -r > > where branch can be either a proper branch or the trunk itself. > > (2) What exactly does HEAD mean? > Is it the head revision of the trunk or of the sand box branch? [smc] Depends on what command you run. for "cvs diff", HEAD means the head revision of the branch sticky tag. for all other commands, as far as I can tell, it means the head revision of the trunk. There are comments in sanity.sh indicating people rely on this broken behavior, which I find hard to believe. (If it said there are "some number of people", I could believe it by setting "some number" to zero. :-) I had posted a patch to bug-cvs to make HEAD work the same for "cvs diff" some time ago. I can probably dig it up, but I didn't see it on deja.com...(I guess they don't monitor bug-cvs...) I had posted a similar patch to introduce TRUNK which behaved the same as my fixed HEAD patch, except preserving the broken behavior of HEAD that people were supposedly relying on. Don't know what happened to either of those patches...they appeared to meet with silent death. -- steve
