[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 12 Mar 2002 09:09:02 -0600
unsubscribe me... I don't want your emails.
From: address@hidden [mailto:address@hidden
Sent: Tuesday, March 12, 2002 8:00 AM
Subject: Info-cvs digest, Vol 1 #1592 - 11 msgs
Send Info-cvs mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Info-cvs digest..."
1. apply rdiff output to patch multiple files (Matthew Herrmann)
2. Re: What forum to propose new port? (Terrence Enger)
3. Your membership (address@hidden)
4. Re: CVS - import to 1.1 (Eric Siegerman)
5. OFF-TOPIC: Spam on the CVS mailing lists (Brian Smith)
7. Re: apply rdiff output to patch multiple files (Larry Jones)
9. clear cvs on sourceforge (Martin =?ISO-8859-15?Q?H=F6fling?=)
10. Re: OFF-TOPIC: Spam on the CVS mailing lists (sudarshan)
11. News Release: How to make the world peaceful and better (Dr. Carter)
From: "Matthew Herrmann" <address@hidden>
To: "CVS Mailing List" <address@hidden>
Subject: apply rdiff output to patch multiple files
Date: Tue, 12 Mar 2002 15:46:50 +1100
I am using 1.11.1.p1 and I'm getting basically one conflict per change on my
I'm using mergepoints ie.
cvs update -j ROT_4_6_1_MERGEPOINT_1 -j ROT_4_6_1_MERGEPOINT_2
in the current directory which I expect would generate a diff between the
two tags and apply the changes. I read there is a bug in the latest
production cvs release where conflicts are spuriously generated. Even in
code which I know has not been modified, it is creating a conflict.
I thought I might be able to avoid this by doing my merge in two steps:
1) generate an rdiff file for the directory (maybe specifying case
insensitivity, ignore blank line changes etc. to reduce conflicts)
2) apply this file using patch
as far as I know, patch only runs on single files. Any way to run rdiff
output? And any idea whether this will help me with my problem? (or maybe
some other workaround, like a switch to specify etc.)
I don't really want to get the latest development release since I'll have to
compile it on two servers and I suppose then update all the client versions
running on Win2k too.(unless there are pre-release binaries available).
Far Edge Technology
Level 11, 80 Mount St
North Sydney NSW 2060
Ph: 02 9955 3640
Mob: 0404 852 537
Date: Tue, 12 Mar 2002 00:04:33 -0500
From: Terrence Enger <address@hidden>
Subject: Re: What forum to propose new port?
At 12:00 PM 2002/03/11 -0500, you wrote:
>Terrence Enger writes:
>> (*) What does it mean? Using an existing distribution of cvs
>> executing on Win95, I have had some success (very small test, no
>> observed problems) controlling ASCII source in the hierarchichal
>> part of the IFS of OS/400. But I can see value in using cvs to
>> control a wider variety of stuff on the 400, ordered by what I
>> would deem to be descending value: source physical file members
>> (there are *lots* of those in the world), EBCDIC files, database
>> files. Others with better imaginations than I can extend the
>That looks like English, but I can't understand a word you said.
Uh-oh. I'm gonna pack up my marbles and go back to coding <grin>. But
>think you're going to have to educate us about the OS/400 environment
>before we can have an intelligent discussion.
Sad, but probably true. Well, not sad for me, as I really like using
OS/400 and talking about it. Stop me if I bore you too much.
OS/400 offers filesystems with a hierarchical directory structure. Mostly,
people used to *nix or Windows would feel quite at home there. In
particular, wherever you are in the hierarchy, cvs can create the cvs
subdirectoy that it wants to create. The small successful test from my
original post involved simply mapping a directory in the hierarchical
directory structure to a network drive on the machine running cvs.
OS/400 also offers one widely used filesystem, "/QSYS.LIB", which is much
more restrictive in many ways. Within this filesystem, source is stored in
"source physical file members". These are at the lowest level of the name
space, and cvs cannot create a subdirectory as a sibling to these members.
No way, No Such Thing, It ain't gonna happen.
("IFS", which stands for Integrated File System, is a naming scheme which
can address all of these things. However, it is the only naming scheme
offered which can address files outside the /QSYS.LIB filesytem, and people
quite often write IFS when they mean specifically the files which only IFS
can address. Let me try that again... People often write "IFS" when they
are talking about what I have called the "filesystems with a hierarchical
I have tried to make cvs work by creating links in the hierarchical
directory structure to source physical file members. Little success, but I
still think it *should* have worked. Someday soon, I shall try again.
> I feel obliged to note,
>however, that CVS was designed to version programming *source* files,
>not arbitrary files. As is frequently discussed here, unless the files
>are divided into lines that can be meaningfully processed with something
>like the Unix 'diff' command, CVS really isn't a very effective tool.
Yes, I have noticed, and even contributed a bit to, that discussion. I did
not want to limit discussion prematurely, but using cvs for OS/400 objects
other than source code is a question for another decade.
>> (*) How much of this change can the main line of development tolerate?
>> I note for example, your discussion "multiplatform sofware desing
>> problem" on bug-cvs with Dimitry Naldaev <address@hidden>, where
>> you take a position against having cvs do code conversions. I can
>> imagine that much--but not all--of the necessary code would be
>> segreated into a platform-specific subdirectory.
>CVS was really designed to work in an ASCII environment. The only
>solution I can imagine for Dimitry's problem would be to rewrite CVS to
>use some universal character set (say, ISO 10646) internally (i.e., in
>the code, in the repository, in the client/server protocol, etc.) and
>convert between that and the system character set on I/O. That would be
>an enourmous amount of work, I suspect it would be difficult to do it in
>an upward compatible form, it would probably make the repository files
>incompatible with RCS, it would significantly increase the size of most
>people's repositories, it would undoubtedly slow down CVS operations,
>and it would probably be a portability problem.
>Changing CVS to work in an EBCDIC-only enviroment should be much less
>work and have much less impact. Even if you do have to interoperate
>between EBCDIC and ASCII, that shouldn't be too much more difficult
>since it is easy to define a useful, invertable mapping between ASCII
>and EBCDIC. (Unfortunately, it is so easy that there are lots of them,
>which could present a problem if all your users can't agree on a single
What part of cvs knows that it is working in ASCII? So far, I have noticed
only a couple of places (and the dependency is implicit). OTOH, I have
only looked at code that the compiler complained about.
I think an OS/400 port would have to work with both ASCII and EBCDIC if we
want it to be widely accepted. That said, there are still design choices
open. For example,
(*) In the simplest way I can imagine working with both code sets,
gives back whatever bit pattern was checked in. The user had better
interpret those bits the right way. This might even be more useful than it
sounds. Lots of installations have all source code in EBCDIC, and I can
imagine that whole projects would have all source code in ASCII. Even for
this simple-minded solution, diff requires work: maybe it even worked when
I used it on an EBCDIC file, but I was reading the output on an ASCII
terminal. So, for all I could tell, it might not even have been close to
(*) With knowledge of code page of a file or member checked in, checkout
can ensure that its output file or member has the same code page. This is
most directly accomplished by storing the code page explicitly in the
repository. Will this be a big deal?
(*) I am tempted to not even think about anything further in this area
until there is demand for it.
>> In my limited study of the code, I see platform-specific files
>> mapping one function to different facilities of the platform but
>> no example of one platform providing more functionality than
>> another. Is there any case where you would like to exploit the
>> particular demands or capabilities of a particular platform? Two
>> special cases could make a pattern; one special case would likely
>> just make a mess.
>I can't think of any. The general philosophy is that CVS should work
>the same way everywhere.
>Aw Mom, you act like I'm not even wearing a bungee cord! -- Calvin
>Info-cvs mailing list
Date: 11 Mar 2002 06:49:10 -0000
Subject: Your membership
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<p>Hot, young first time amateurs can be found from all over the world.<a
Every country has its own breed of dirty little skanks</a> who are begging
lick a hard cock and put their sloppy wet lips around a pussy</p>
<p>. The only place you can see the creamiest, nasty, young amateurs from
the world, and that is here!!<a
If you want tons of naughty, wet, hardcore fuck action, then click
<p><a href="http://newfree.com/blondam/index.html">Slutty Amateurs do it
<p><a href="http://220.127.116.11/cancel.php">Click here and enter your email
to cancel further mailings!</a></p>
Date: Tue, 12 Mar 2002 00:28:32 -0500
From: Eric Siegerman <address@hidden>
Subject: Re: CVS - import to 1.1
Organization: Telepresence Systems Inc.
Greg answered most of your questions. Let me just fill in one
On Mon, Mar 11, 2002 at 09:22:44PM -0500, Matthew Persico wrote:
> I always though that in the presence of a branch, a command w/o a -r
> worked on latest revision, main line code.
*Except* for the vendor branch. The rule is: if a file was
imported to the vendor branch, and nobody has yet checked in any
local changes on the trunk (i.e. if the version of the file on
the vendor branch is still current), then (and only then) the
default revision is the latest one on the vendor branch.
More specifically, the default revision is always the latest one
on the "default branch".
The default branch is usually the trunk. But when you first "cvs
import" a new file foo, CVS sets its default branch to the
vendor branch (1.1.1, unless you specified otherwise). The first
time someone "cvs commit"s a new revision of foo *to the trunk*,
CVS switches the default branch to the trunk; and there it stays
forevermore, unless you do the "revert" thing talked about in the
manual. If you later "cvs import" a new revision to the vendor
branch, the default branch is NOT changed; it stays wherever it
The net effect of all this is:
- If a file was first made known to CVS via "cvs import",
and no local changes have been committed to it (i.e. the
highest trunk revision is 1.1), then the "default branch"
is the vendor branch
- In *all* other circumstances, the default branch is the
(Actually, there's one other way for the default branch to
change: someone can change it manually. But, except for
reverting to the vendor branch as described in the manual, you
should *never* do this.)
"cvs log" tells you which branch is the default for a given file;
look for the "branch:" line. If no value is shown, the trunk is
the default branch.
> I guess I need to re-read how branches work.
I was going to tell you to read the "third-party sources"
section, but that doesn't seem to explain this in any detail.
Neither does the reference node on "cvs import". There are
hints, but they'd probably only be comprehensible to someone who
already understood the situation. E.g. there are a number of
references to the default branch, but I can't find any
explanation of what that is or how CVS uses it. *sigh*
So now that I've explained it a bit, try rereading the two
sections I mentioned:
With luck, those hints that didn't make any sense before will
jump out at you this time through :-)
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. address@hidden
| | /
"Outlook not so good." That magic 8-ball knows everything!
I'll ask about Exchange Server next.
Date: Mon, 11 Mar 2002 23:46:18 -0600
From: Brian Smith <address@hidden>
Subject: OFF-TOPIC: Spam on the CVS mailing lists
I have received a lost of spam from this mailing list. I know there are
other lists using the same mailing list software, and they do not have a
spam problem. It seems that the CVS mailing lists don't have the "sender
must be a member of the list to send a message to the list" option
selected. I think such a requirement would benefit everybody subscribed
to the list
Date: Tue, 12 Mar 2002 16:00:10 +0800
This is a multi-part message in MIME format
Content-Type: text/plain; charset=gb2312
=B9=E3=B6=AB =B9=FA =BC=CA=A1=EF=A1=EF=A1=EF=A1=EF=A1=EF=A3=A4485
=BD=AD=CD=E5 =BE=C6 =B5=EA=A1=EF=A1=EF=A1=EF=A1=EF=A3=A4350
=BC=CE=D3=A6 =BE=C6 =B5=EA=A1=EF=A1=EF=A1=EF=A1=EF=A3=A4350
=D3=AD =B1=F6 =B9=DD =A1=EF=A1=EF=A1=EF=A1=EF=A3=A4360
=CE=C4=BB=AF =BC=D9 =C8=D5=A1=EF=A1=EF=A1=EF=A1=EF=A3=A4430
=BE=B0=D0=C7 =BE=C6 =B5=EA=A1=EF=A1=EF=A1=EF=A1=EF=A3=A4330
=D5=D0=C9=CC =B1=F6 =B9=DD=A1=EF=A1=EF=A1=EF=A1=EF=A3=A4300
=B0=D7=D4=C6 =B1=F6 =B9=DD=A1=EF=A1=EF=A1=EF=A3=A4280=D6=F7=C2=A5
=BD=F0=D2=B6 =B4=F3 =CF=C3=A1=EF=A1=EF=A3=A4150
=C5=ED=C4=EA =BE=C6 =B5=EA=A1=EF=A1=EF=A1=EF=A1=EF=A1=EF=A3=A4698=A1=A1
=D1=F4=B9=E2 =BE=C6 =B5=EA=A1=EF=A1=EF=A1=EF=A1=EF=A1=EF=A3=A4690
=DC=BD=C8=D8 =B1=F6 =B9=DD=A1=EF=A1=EF=A1=EF=A3=A4280
=B9=E3=C9=EE =B1=F6 =B9=DD=A1=EF=A1=EF=A1=EF=A3=A4200
=BD=A8=B9=A4 =B1=F6 =B9=DD=A1=EF=A1=EF=A3=A4180
Subject: Re: apply rdiff output to patch multiple files
To: address@hidden (Matthew Herrmann)
Date: Tue, 12 Mar 2002 03:36:38 -0500 (EST)
Cc: address@hidden (CVS Mailing List)
From: address@hidden (Larry Jones)
Matthew Herrmann writes:
> as far as I know, patch only runs on single files. Any way to run rdiff
> output? And any idea whether this will help me with my problem? (or maybe
> some other workaround, like a switch to specify etc.)
rdiff (aka patch) output wouldn't be very useful if patch wouldn't
process it, now would it? patch is perfectly happy to run on multiple
> I don't really want to get the latest development release since I'll have
> compile it on two servers and I suppose then update all the client
> running on Win2k too.(unless there are pre-release binaries available).
In general, the server does all the work, so upgrading just the servers
should solve the problem.
Summer vacation started! I can't be sick! -- Calvin
Date: Tue, 12 Mar 2002 19:44:33 +0800
From: Martin =?ISO-8859-15?Q?H=F6fling?= <address@hidden>
Subject: clear cvs on sourceforge
Date: Tue, 12 Mar 2002 12:47:24 +0100
Organization: Department of Computer Sciences, University of Munich
i made some mistakes and now I have following problem:
I want to delete all modules on my sourceforge project but I have no idea.
Thanx for help
Date: Tue, 12 Mar 2002 19:20:00 +0530 (IST)
From: sudarshan <address@hidden>
Subject: Re: OFF-TOPIC: Spam on the CVS mailing lists
Yes i do accept the comments what brian has told. Even i am a member
of CVS mailing list and past one week i am getting around numerous
SPAM mails and the character set is not english and it is very
Could some body can stop this
I have received a lost of spam from this mailing list. I know there
other lists using the same mailing list software, and they do not have
spam problem. It seems that the CVS mailing lists don't have the
must be a member of the list to send a message to the list" option
selected. I think such a requirement would benefit everybody
to the list
Info-cvs mailing list
From: "Dr. Carter" <address@hidden>
To: "address@hidden" <address@hidden>
Subject: News Release: How to make the world peaceful and better
Date: Tue, 12 Mar 2002 08:57:06 -0500
Content-type: text/plain; charset="iso-8859-1"
March 12, 2002
For release as soon as you can
Contact: Dr. Tom Carter, President
Nicer Century World Organization
How to make the world
peaceful and better
The solution can be found in the book:
"Complete Conduct Principles for the 21st Century" by Dr. John Newton;
ISBN 0967370574 (hardcover) or ISBN 0967370582 (paperback).
Let's work together to make the world peaceful and better!
--- END ---
(Nicer Century World Organization is an educational, non-profit,
organization; it endeavors to make the 21st century nicer than ever before.
To accomplish its mission, Nicer Century World Organization is proud to
Content-Type: text/html; charset="iso-8859-1"
<META NAME=3D"GENERATOR" Content=3D"GroupHTML Plugin for Group Mail">
<P align=3Dright>March 12, 2002</P><I>
<P>For release as soon as you can </P></I>
<P align=3Dright>Contact: Dr=2E Tom Carter, President</P>
<P align=3Dright>Nicer Century World Organization</P>
<P align=3Dright>Massachusetts USA</P></FONT><I><U><FONT color=3D#ff0000 s=
<P align=3Dcenter>News Release</P></I></U></FONT><B><FONT face=3D"Times Ne=
<P align=3Dcenter>How to make the world </P>
<P align=3Dcenter>peaceful and better</P></B></FONT><FONT face=3D"Times Ne=
<P>The solution can be found in the book: </P>
<P>"<I>Complete Conduct Principles for the 21st Century</I>" by Dr=2E John=
<P>ISBN 0967370574 (hardcover) or ISBN 0967370582 (paperback)=2E</P>
<P>Let's work together to <FONT face=3D"Times New Roman">make the world pe=
<P align=3Dcenter>--- END ---</P></I></FONT>
<P>(<I>Nicer Century World Organization</I> is an educational, non-profit,=
non-partisan organization; it endeavors to make the 21st century nicer tha=
before=2E To accomplish its mission, <I>Nicer Century World Organization</=
proud to introduce the book=2E)</P>
Info-cvs mailing list
End of Info-cvs Digest
|[Prev in Thread]
||[Next in Thread]|
Mike Nilsson <=