From: Christine Freight ([EMAIL PROTECTED])
I am having a dispute with a co-worker over how to do something in CVS. I
was wondering if anyone out there can help? Here's the situation:
A branch (let's call it branchA) gets created off the main line. Then, at
some point in time, a branch
Hi,
For anybody using my .trunk + .origin patch,
( http://www.geocities.com/dotslashstar/branch_patch.html ):
I have a new version. I found a tiny problem if
you specify .origin by itself, (which is not allowed
anyway) it would add an invalid line into the val-tags
file.
If you do, for
Tinkering around with my .trunk + .origin patch, I realized if it were ever
to make it into mainstream CVS, there will inevitably be interaction between
unpatched clients and patched servers and also between patched clients and
unpatched servers.
One would hope that they would behave reasonably
Tim Wensink wrote:
Hello all,
I have a question regarding CVS tags. I want to have a list of files
that are in a certain release. Is there a command within (win)cvs that
allows me to specifiy a certain tag and then generates a list of all
the files that have that tag?
Saw lots of
Ralph Mack ([EMAIL PROTECTED]) wrote:
[...]
What I'm reading about branching and merging makes me think that
a branch-merge pair on CVS is a one-way trip, that once you have
merged from a branch you can't merge to that branch from the
updated mainline and then merge back again. Another
--- Derek R. Price [EMAIL PROTECTED] wrote:
Stephen Rasku wrote:
cvs admin -o uses a colon syntax to specify a revision range and cvs log
uses the same (or similar) syntax to specify revisions (except for the
space problem mentioned above) but it uses a different syntax for dates.
Tony Mantler wrote:
basically I type...
cvs update -jHEAD -jHEAD:yesterday
and it doesn't do what he expects.
Well, I don't know what to say about that, but at the very least, you did lead
me to find a gaping hole in my .trunk patch. I tried
cvs update -j.trunk -j.trunk:yesterday
to see
Hi, I've checked out CVS sometime ago from cvs.cvshome.org,
and now I do:
[scameron@zuul ccvs]$ cvs -z3 -nq update
? lib/.deps/argmatch.Po
? lib/.deps/dup2.Po
? lib/.deps/fncase.Po
[ ... loads more ? files...]
? src/.deps/[loads of ? files...]
Should there be .cvsignore entries for
Donald Sharp wrote:
I have a user who manged to delete a branch( it looks like
with the cvs rtag -d command ). When I went poking at
the ,v file it looks like the revisions for that branch
are still around.
Is it ok to just put the branch name and revision back into the ,v
files?
Yes,
One point I forgot to mention in my previous post:
I wrote:
When a new branch is to be created (when development on a
new release is to begin) the current newest branch is
merged to the trunk, then the new branch is created off
the trunk.
What I forgot to mention was that since no
Richard Cobbe wrote that he wanted suggestions about merging...
I can tell you what we do, and you can see if it might make sense
for you.
We do all development and bugfixes on branches. We don't really use
the trunk for any development at all. We have "official" branches that
everybody
For any who are interested, I've updated my ".trunk" + ".origin" patch
vs. the current (nov 1, 2000) development version of CVS.
http://www.geocities.com/dotslashstar/branch_patch.html
Only change since last time is change to sanity.sh to account
for recent fix to "cvs add" to handle "-Q" option.
If anybody's interested,
I regenerated my ".trunk" + ".origin" patch against CVS 1.11
and made minor cosmetic changes plus added one more test to
sanity.sh for "cvs annotate".
http://www.geocities.com/dotslashstar/branch_patch.html
As always, let me know if you find any problems, or
if I've
Greg Woods wrote:
I'm having no end of trouble trying to "cvs update" in my working
directory checked out from the anonymous repository...
Just a datapoint:
I was able to do several "cvs -z3 update" last night ok...
and "cvs -z3 diff -c" too... It was kind of
slow, but I _was_ on a 56k
Alexander N. Spitzer writes:
If this is a common question, then I am sorry. I have spent a couple hours
on google, and ftp-mailing-list-archives.gnu.org/mailing-lists/info-cvs,
and still have no answer
question:
mainline
\
\___branch-1_0_0_
branch-1_0_0 is
__
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
(sorry about prior empty message)
James Youngman wrote:
Before checking code in I like to check what changes
I've made in order to ensure that I have in my mind
all the comments that need to be made at "cvs commit".
I also like to do this periodically to ensure that
I haven't forgotten
The biggest thing CVS has going for it over MKS SI
is the (mostly) automatic merging of branches on
a project- or module-wide basis using 3-way diffs.
MKS merging is file-by-file, and is 2-way diff based
manual process, (or was, last time I checked, which was
a year ago or so).
A couple other
On Thu, 07 Sep 2000, Benjamin Balagot wrote:
Hello,
I'm new to CVS and would like to find some answers.
We have a BRANCH e.g. branch1 that was branched off
the main line
and another branch e.g. branch2 that I recently
branched off the main line.
How can I merge the 2 branches so
Mike Castle wrote:
So, for your situation, yuou have something like this:
Branch point
v
0+ Main
|
+--- Test
Now, hopefully you labled the branch point
with something when you created
the branch. Otherwise, this is a pain.
(Allow me to advertise
Noel Yap wrote:
Is there really a reason why "-A" doesn't work when the
update command is also given "-D" or "-r"?
Yes. (without my ".trunk" patch) this is how you update your
working directory to the trunk, with "-A". "-A" means get rid
of the sticky tags (and sticky options too). "-D"
--- Stephen Rasku [EMAIL PROTECTED] wrote:
Date: Wed, 19 Jul 2000 22:46:42 -0700 (PDT)
From: Stephen Cameron [EMAIL PROTECTED]
[...]
It seems to me that moving a branch tag is almost NEVER the
right thing to do, while moving a non-branch tag is a (comparatively)
normal operation...
I
David Thornley wrote:
(The biggest single problem I get is when people type
cvs tag -F RELEASE_x_y
rather than
cvs tag -F RELEASE_x_y_MERGED
where the first is the branch tag
It seems to me that moving a branch tag is almost NEVER the
right thing to do, while moving a non-branch tag is a
Update of my ".trunk" + ".origin" patch:
I fixed a bug with "cvs commit -r .trunk" plus
ChangeLog entry, and some changes to sanity.sh
test cases and docs and misc. other changes.
July 9 2000 version of this patch can be found here:
http://www.geocities.com/dotslashstar/branch_patch.html
Is the cvs.cyclic.com:/home2/cvs modules file corrupted?
I try:
[scameron@zuul cvs.ctd]$ echo $CVSROOT
:pserver:[EMAIL PROTECTED]:/home2/cvsroot
[scameron@zuul cvs.ctd]$ export CVSROOT
[scameron@zuul cvs.ctd]$ cvs -z3 co -c
ccvs @ÐàÈ
[scameron@zuu[scameron@zuul cvs.ctd]$
And I try:
I wrote:
I just tried my 6-28-2000 ".trunk" patch
against 1.10.8 on SCO unixware 7.
It failed log-14.
Ah. Now that I'm home, I sse the problem.
The diffs between the 1.10.8 and the development
version are too great for my patch to work with
1.10.8.
Somebody on this list asked awhile ago about
how to write sanity.sh test cases, (now I
can't seem to find the message though.)
It occurred to me that I know a thing or two
about that, and it also occurred to me that it
was hard-won knowledge.
So I took a few minutes to write some of it
down.
hangeLog
===
RCS file: /home2/cvsroot/ccvs/doc/ChangeLog,v
retrieving revision 1.622
diff -c -r1.622 ChangeLog
*** ChangeLog 2000/06/14 17:41:56 1.622
--- ChangeLog 2000/06/27 05:26:23
***
*** 1,3
--- 1
John P. Cavanaugh wrote, regarding his preference for "main" or "trunk"
over ".trunk":
Partly for personal preference of liking main or trunk better than .trunk.
But it also allows for main.latest (which I will admit is only to facilitate
similarity with other branches)
So, it's partly for
I have a new version of my ".trunk" patch (I sent it to bug-cvs
already but I didn't want to pollute everyone's mailbox
with a big patchfile twice, so I'm only sending this
URL to info-cvs...
Includes a new test case in sanity.sh for a revision "2.1"
Changes to docs, comments...minor stuff.
Just out of curiosity, I used my hacked version of
cvs to do this on my biggest repository:
cvs rdiff -s -r1 -r.trunk topmodule diffs.txt
There were 459 (out of 6658) files that had
a revision number that didn't start with "1",
and quite a few that I was surprised to see.
(that is, quit a
Well, I see one problem with my patch already:
--- Stephen Cameron [EMAIL PROTECTED] wrote:
This part, from cvs.texinfo:
+
+ CAUTION: the special tag `HEAD' is interpreted by
+ the `cvs diff' command in a different way than it
+ is interpreted by any other cvs command. `cvs diff'
+ takes `-r
2000/06/14 17:41:56 1.622
--- ChangeLog 2000/06/18 04:19:47
***
*** 1,3
--- 1,7
+ 2000-06-18 Stephen Cameron [EMAIL PROTECTED]
+
+ * cvs.texinfo: Document new ".trunk" pseudo branch tag.
+
2000-04-03 Pavel Roskin [EMAIL PROTECTED]
* cvs.tex
[EMAIL PROTECTED] (that's me) wrote:
[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
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
35 matches
Mail list logo
