Re: BRANCH LABEL FOR DIRECTORIES

[Paul Sander]

>--- Forwarded mail from [EMAIL PROTECTED]

>[ On Sunday, June 17, 2001 at 10:40:03 (-0700), Paul Sander wrote: ]
>> Subject: Re: BRANCH LABEL FOR DIRECTORIES

>Paul, quit spreading F.U.D.!

>CVS NEVER automatically deletes ANY version history whatsoever!
>Therefore, obviously, in CVS the revision history DOES survive!

No, it doesn't delete it, but it does hide the old stuff (which is just
as bad).  Once the remove-add sequence is done, there is no reliable
method to track down the original location, and under some circumstances
there may even be no way for the end user to recover it.

>Revision history for renamed files is TRIVIAL to find and examine!!

I beg to differ.  Even in your preferred method, you rely on the user
to carefully leave a bread crumb trail, by noting the rename in the commit
comment.  The version control system should track the rename separately,
in the version history but separate from the user's comments.

>> Next, you're going to say that there's no problem here that a linked list
>> can't solve.  But there is:  In CVS, the list must track all branches to
>> the original source to support merges properly.

>Nobody said anything about supporting merges across renames.  Such a
>feature is simply not necessary in a basic version tracking system like
>CVS.  It could of course be built on top of CVS though (eg. as a wrapper
>script, or in a custom client).

You're kidding, right?  Don't support merging across renames?  This
capability is one of the most basic requirements of any version control
system worthy of the name.

>In the mean time for those few times when renames and merges are
>necessary it is relatively easy for a user to do a manual merge.  All
>the revision history, including all past deltas, is still there to
>extract.

What if you rename the top directory of a deep tree?  That's a LOT of
manual merging to do.  And sometimes the rename is necessary.  And
sometimes the users expect the rename operation to be both reversible
and repeatable.  CVS does not provide this capability in any sense.

>>  Worse, if the original file
>> is re-added as a different type, then appending it to the old version history
>> is useless and possibly harmful.

>People using different file "types" in CVS are already doing things well
>beyond the design goals of CVS and are therefore strictly on their own.
>CVS does not really have any proper concept of file "types", after all.

Okay, let's pick nits and say only that the format of the data contained in a
file changes.  Let's say that it changes from RTF to HTML.  Strictly speaking,
the file's "type" does not change, but using CVS in the normal way produces
gibberish in certain cases that are easy for the average user to fall into.
This just would not happen if version histories tracked the entire lifetime
of a file, not just that portion of its life when it occupied one spot in
the filesystem.

>>  It's much better to keep a file's complete
>> revision history over its entire lifetime (regardless of its location in
>> the filesystem), and to keep version histories unique for each file
>> (even if it occupies the same place in the filesystem as another file
>> on differing branches or different stages of the product's lifecycle).

>Paul you are ignoring some fundamental aspects of CVS, much to your
>detriment (and to those of people who don't critically review what you
>write).  CVS cannot do what you think you want it to do, in the way you
>think you want it to.  Perhaps you should unsubscribe from this list and
>go seek help elsewhere.

>Meanwhile the people who wish to understand and use CVS properly can
>learn that CVS tracks the revision history not by it's logical content,
>but rather by its label and position.  Renaming a file within CVS is
>simply a matter of stopping the use of one label in one position and
>starting the use of another label in another position.  This should be a
>very simple concept to learn, and indeed with a little experimentation
>CVS can demonstrate these concepts with great clarity.

No, I'm not ignoring some fundamental aspects of CVS; I'm exposing them.
The correct way to track revision history is to keep its logical content,
label, and position inseparable.  When one changes, the rest must follow.
CVS does not do this, that fact causes a lot of problems for a lot of
users.

>Of course people reading the manual should also be warned that it is
>still somewhat misleading and gives some very very bad and self-
>contradictory advice on the topic of renames.  The only correct way to
>rename a file is that described in the node "The Normal way to Rename".
>The "Moving the history file" trick is just plain wrong -- such a thing
>should never ever Ever EVER be done (if you want to use CVS properly),
>and the manual should simply warn never to do it (and people who think
>they know better can void their warranty if they want).  The trick
>dscribed in the "Copying the history file" node is also wrong as i

Re: BRANCH LABEL FOR DIRECTORIES

[Paul Sander]

>--- Forwarded mail from [EMAIL PROTECTED]

>[ On Sunday, June 17, 2001 at 20:26:34 (-0400), Ralph Mack wrote: ]
>> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>>
>> Well, that depends upon what you mean by "an addition", doesn't it,
>> Greg? If you mean the deletion of the old object with all of its baggage
>> and the creation of a new object _with all of the old object's baggage_,
>> I would tend to agree that the sequence implements the concepts of
>> renaming or moving an object.

>Yes, of course -- a rename is an addition "with all the old object's baggage".

And in a version control system, that baggage includes the file's entire
revision history, by definition.

>> In a Unix file system, that baggage consists of a set of permissions,
>> owner and group assignments, and perhaps a couple of things that I
>> forget, but is nonetheless a relatively light bundle.

A file under version control is not a normal Unix file.  A specific
revision of the file could be.  But there's a difference that you choose
to ignore.

>> A file under revision control has a history of revisions (and - one hopes -
>> ancestors and migrations) that describe all the important events of its
>> colorful life. Does moving or renaming a file by deletion and addition
>> retain the file's family history? It sounds to me as if it reduces it to a
>> Unix file with none of these attributes and then recreates it as if it were
>> newborn. All connection to the past is lost.

>In CVS the history stays in place (it must, by design).  It's like the
>unix filesystem in the sense that the data blocks, and indeed the inode
>structure itself, stay in place when you rename the file (though in some
>senses that's a terrible analogy for my purposes since in CVS you do
>actually have to carry more of the baggage yourself! ;-).

And in a version control system, the revision history maps to the data
blocks, and it's up to the system to provide the correct view of whatever
versions the users choose to place in their sandbox.  The version history
changes over time, but no matter how the user links to it, they see the
same thing.  And depending on how the user selects the file, they not
only see a different path to it, they may see different contents as well.
This is a fundamental version control concept.

>> Do you regard this loss as a frivolous concern?

>THERE IS NO LOSS!  In fact if you do the remove and add with appropriate
>commit comments there's actually an information gain -- and anyone
>looking at the revision history of the files (from either direction)
>will be able to follow what has happened with great accuracy.

>> To me the power of source
>> control lies not just in its ability to store all the versions of software
>> but to accurately reflect the historic relationships of those versions.

>CVS will not delete any revision history if you do a rename by way of
>"cvs add" and "cvs rm" -- on the contrary it will add history entries
>which detail this ``change'', provided that you (or your wrapper script
>or front-end client) provide the appropriate change comments for each
>operation.  Time for a concrete CVS example, I think:

>   cp oldfile.c newfile.c
>   cvs rm -f oldfile.c
>   cvs add newfile.c
>   cvs commit -m 'renamed oldfile.c to newfile.c' oldfile.c newfile.c

>Now if you do "cvs log" on either name you'll find it very hard to miss
>what's actually happened.  If the comment is even more detailed the
>reason might even be apparent after the fact too!  ;-)

Okay, now consider this:

cp olddir/oldfile.c newdir/newfile.c
cp olddir/oldfile2.c newdir/newfile2.c
cvs rm -f olddir/*
cvs add newdir/newfile.c newdir/newfile2.c
cvs commit -m 'reorganized source to be better'
cvs update -P

Guess what:  The old revision history is now hidden from the user.  To
see the revision history of either of either file prior to the rename,
he must figure out what tags (if any) have been applied to the files prior
to the rename, use one of them to check out the module, and bounce back
and forth between the two workspaces to see everything.

>Think of the "cp" and combined "commit" parts of this sequence as the
>baggage carrying bits.  The "cp" copies the current contents, and the
>"commit" leaves pointers to the past and future revisions.
>Hmmm... maybe that analogy with the unix directory tree isn't so bad
>after all.  In Unix you have to "carry" the name (transforming it on the
>way if it stays in the same directory or changes in the new directory),
>while in CVS you have to carry both the name and the current file
>contents.  In both the attributes (in Unix the file blocks and the inode
>structure; and in CVS the revision history) stay in place.

Except that in CVS the revision history does not remain in place; a new
RCS file has been created, and it is modified from that time forward
while the old one is ignored.

>What I find is really most important about the relationships of
>revisions is not how they relate to one another along

$DateZone: (ZONE)$ (was RE: $DateLocal$)

[KOIE Hidetaka]

I come again,
implement `$DateZone: (ZONENAME)$'.

  From:   [EMAIL PROTECTED] (Larry Jones)
  Subject:Re: $DateLocal$
  Date:   Sat, 16 Jun 2001 00:37:51 +0900
  Message-Id: <[EMAIL PROTECTED]>

  | KOIE Hidetaka writes:
  | > 
  | > I implement $DateLocal$ keyword expansion using strftime().
  | > Is this a bad idea?
  | 
  | Probably:
  | 
  | 1) The "local" time you're using is the local time of the server, not
  | the local time of the client.

In this implementation, a writer specifies the timezone.
Then, the behavior is a place-independent.

  | 2) Your code assumes that the differential between local time and UTC is
  | always the same as it is currently, which isn't true for all of us that
  | have "daylight saving" or "summer" time.


A problem of this implementation is
the literal ZONENAME depends on OS.
How to check what literal accepts, try "env TZ=ZONENAME date".
In freebsd and linux, look under /usr/share/zoneinfo.
In Solaris, /usr/share/lib/zoneinfo. For example:
I'm in Japan and uses freebsd, then
write "$DateZone: (Asia/Tokyo) 2001/06/18 19:10:22 JST $".

Note: SPACE must be placed after colon for the program ident in RCS.

I dont know about summer time,
because no summer time in Japan, sorry.
I'm hoping for solved.

--
KOIE Hidetaka <[EMAIL PROTECTED]> in Japan.


Index: lib/getdate.c
===
RCS file: /home2/cvsroot/ccvs/lib/getdate.c,v
retrieving revision 1.21
diff -u -p -r1.21 getdate.c
--- lib/getdate.c   2 Apr 2001 19:10:15 -   1.21
+++ lib/getdate.c   18 Jun 2001 10:16:43 -
@@ -1660,7 +1660,17 @@ Convert(Month, Day, Year, Hours, Minutes
Julian -= 60 * 60;
 return Julian;
 }
-
+time_t
+convert_date(Month, Day, Year, Hours, Minutes, Seconds)
+time_t Month;
+time_t Day;
+time_t Year;
+time_t Hours;
+time_t Minutes;
+time_t Seconds;
+{
+return Convert(Month, Day, Year, Hours, Minutes, Seconds, MER24, DSTmaybe);
+}
 
 static time_t
 DSTcorrect(Start, Future)
Index: src/cvs.h
===
RCS file: /home2/cvsroot/ccvs/src/cvs.h,v
retrieving revision 1.222
diff -u -p -r1.222 cvs.h
--- src/cvs.h   25 May 2001 14:48:08 -  1.222
+++ src/cvs.h   18 Jun 2001 10:16:43 -
@@ -493,6 +493,8 @@ int update PROTO((int argc, char *argv[]
 int xcmp PROTO((const char *file1, const char *file2));
 int yesno PROTO((void));
 void *valloc PROTO((size_t bytes));
+time_t convert_date(time_t Month, time_t Day, time_t Year,
+   time_t Hours, time_t Minutes, time_t Seconds);
 time_t get_date PROTO((char *date, struct timeb *now));
 extern int Create_Admin PROTO ((char *dir, char *update_dir,
char *repository, char *tag, char *date,
Index: src/rcs.c
===
RCS file: /home2/cvsroot/ccvs/src/rcs.c,v
retrieving revision 1.248
diff -u -p -r1.248 rcs.c
--- src/rcs.c   7 Jun 2001 19:10:26 -   1.248
+++ src/rcs.c   18 Jun 2001 10:16:45 -
@@ -3349,27 +3349,32 @@ struct rcs_keyword
 {
 const char *string;
 size_t len;
+int has_arg;
 };
-#define KEYWORD_INIT(s) (s), sizeof (s) - 1
+#define KEYWORD_INIT(s) (s), (sizeof (s) - 1)
 static const struct rcs_keyword keywords[] =
 {
-{ KEYWORD_INIT ("Author") },
-{ KEYWORD_INIT ("Date") },
-{ KEYWORD_INIT ("Header") },
-{ KEYWORD_INIT ("Id") },
-{ KEYWORD_INIT ("Locker") },
-{ KEYWORD_INIT ("Log") },
-{ KEYWORD_INIT ("Name") },
-{ KEYWORD_INIT ("RCSfile") },
-{ KEYWORD_INIT ("Revision") },
-{ KEYWORD_INIT ("Source") },
-{ KEYWORD_INIT ("State") },
-{ NULL, 0 }
+{ KEYWORD_INIT ("Author"),0 },
+{ KEYWORD_INIT ("Date"),  0 },
+{ KEYWORD_INIT ("DateLocal"), 0 },
+{ KEYWORD_INIT ("DateZone"),  1 },
+{ KEYWORD_INIT ("Header"),0 },
+{ KEYWORD_INIT ("Id"),0 },
+{ KEYWORD_INIT ("Locker"),0 },
+{ KEYWORD_INIT ("Log"),   0 },
+{ KEYWORD_INIT ("Name"),  0 },
+{ KEYWORD_INIT ("RCSfile"),   0 },
+{ KEYWORD_INIT ("Revision"),  0 },
+{ KEYWORD_INIT ("Source"),0 },
+{ KEYWORD_INIT ("State"), 0 },
+{ NULL, 0, 0 }
 };
 enum keyword
 {
 KEYWORD_AUTHOR = 0,
 KEYWORD_DATE,
+KEYWORD_DATELOCAL,
+KEYWORD_DATEZONE,
 KEYWORD_HEADER,
 KEYWORD_ID,
 KEYWORD_LOCKER,
@@ -3400,6 +3405,88 @@ printable_date (rcs_date)
 return xstrdup (buf);
 }
 
+static char *
+printable_date_local (rcs_date)
+ const char *rcs_date;
+{
+int year, mon, mday, hour, min, sec;
+char buf[100];
+
+(void) sscanf (rcs_date, SDATEFORM, &year, &mon, &mday, &hour, &min,
+  &sec);
+if (year < 1900)
+   year += 1900;
+
+{
+   time_t t;
+   struct tm gmt, local;

Re: Using another port in commandline

[Matthew Riechers]

Michael Wenig wrote:
> 
> How is it possible to use command-line cvs using pserver listening on a
> port other than 2401?
> 
> Thanks Micha

Yes: http://cvshome.org/docs/manual/cvs_2.html#SEC30

-Matt

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

(no subject)

[Amitabh Trivedy]

Hi,
I'm getting this  error

1."cvs server: cmgi_us_hr_ldap_phone_view.sql added independently by second 
party " .I added the file from Unix .
2. cannot add file  when RCS file  already exists.
When i was trying to add the same file from CVS .


Could you tell me pls how to get out of this error ?


Regards,
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Taginfo question

[Mark]

Since taginfo is in a sense, a pre-op trigger, the tag won't be
placed in the RCSfile until the taginfo script successfully exists.

But the rlog command will, of course, work in helping to identify
existing tags.

--- Andy Baker <[EMAIL PROTECTED]> wrote:
> No reason why you can't run an 'cvs rlog -h' on the file in your
> taginfo
> script and work it out.
> 
> -Original Message-
> Is there any way to determine, in a taginfo script, whether or
> not
> a tag being created/applied is a branch tag or not?


__
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Taginfo question

[Andy Baker]

Ah. I see (next time I'll read the posting properly!). Good 'un that.
Nothing obvious springs to mind.

-Original Message-
From: Mark [mailto:[EMAIL PROTECTED]]

Since taginfo is in a sense, a pre-op trigger, the tag won't be
placed in the RCSfile until the taginfo script successfully exists.

But the rlog command will, of course, work in helping to identify
existing tags.



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

problem with windows client

[Michael_Hinz]

(english mail below)

Hallo,

wir benutzen folgende Betriebsysteme:

cvs server: suse linux 7.1, mit der cvs version 1.11
cvs client: ms windows nt workstation, version 4.0

Kommunikation zwischen server und client: Samba 2.0.7

Folgendes Problem tritt auf:
Wenn unter Windows ein benutzer ein "cvs commit" absetzt, und er hat die Datei nicht selbst in das repository importiert (was meistens der fall ist) dann kommt folgende Fehlermedlung:
--
Checking in io_oic.dsp;
\\msg-4k\local\proj\cvsroot\/proj/visualc/oracle/io_oic/Attic/io_oic.dsp,v  <--  io_oic.dsp
new revision: 1.1.2.4; previous revision: 1.1.2.3
cvs [commit aborted]: cannot rename file \\msg-4k\local\proj\cvsroot\/proj/visualc/oracle/io_oic/Att
ic/,io_oic.dsp, to \\msg-4k\local\proj\cvsroot\/proj/visualc/oracle/io_oic/Attic/io_oic.dsp,v: File
exists
--

Es waere mir sehr geholfen, wenn mir jemand eine moegliche Loesung fuer diese Problem geben koennte.

Mit freundlichen Gruessen


Michael Hinz





Hello,

we are using different operating systems:

cvs server: suse linux 7.1, with cvs version 1.11
cvs client: ms windows nt workstation, version 4.0

Communication between server and client : Samba 2.0.7

The following problem occurs:

If a user types a "cvs commit" and has not imported this file into the repository ( what normally is the case ) following error message appears:
--
Checking in io_oic.dsp;
\\msg-4k\local\proj\cvsroot\/proj/visualc/oracle/io_oic/Attic/io_oic.dsp,v  <--  io_oic.dsp
new revision: 1.1.2.4; previous revision: 1.1.2.3
cvs [commit aborted]: cannot rename file \\msg-4k\local\proj\cvsroot\/proj/visualc/oracle/io_oic/Att
ic/,io_oic.dsp, to \\msg-4k\local\proj\cvsroot\/proj/visualc/oracle/io_oic/Attic/io_oic.dsp,v: File
exists
--

It would be very kind if someone knows a possible solution for this problem and commit it to me.

Sincerely

Michael Hinz

Re: problem in cvs client/server conf

[Matthew Riechers]

prasad marumokham wrote:
> 
> Hello,
> I have redhat linux 7.0 server.
> I had installed cvs-1.11.1 and ssh-2.4.0 .
> I have some problem in client/server configuration.
> I am also followed CVS manual while configuring client/server, in manual they have 
>given /etc/inetd.conf,.rhosts  files which have to be modified .
> But Iam unable to find those files in my system.
> Can I get any alternative files .
> Please help me.
> 
> Thanking you,
> 
> Prasad MVD,
> Tera Software Ltd.,
> Hyderabad,A.P,India.
> [EMAIL PROTECTED]

I believe RedHat 7.0 uses xinetd by default. Try looking in the archives
for this list for more info, or 'man xinetd'.

-Matt

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs history file is huge, can it be removed?

[Kevin Tomasek]

I have spent some time looking throught the cvs discussion list and didn't
see what i was looking for.  I did see your name quite often though, hence
the mail.

my question is ..  can the history file be deleted?  moved and create a new
history file?

the manual says that the history file is used if it exists, is this true?
if i don't have one it won't create one?

the reason for this question is our history file is MASSIVE!!  backing up
the repo is long for this one file!

i would like to compress the present and start a new one, although the times
i have tried to use the history file have been pretty useless, it would seg
fault.  i do want to make sure the cvs doesn't stop working because of this
action.

thanks  Kevin T..

ps.  maybe this should be a FAQ on the cvs home page??



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

[Fwd: CVS clients on windows 2000 with gssapi]

[Derek R. Price]

Please send these sorts of posts to [EMAIL PROTECTED] rather than
directly to me.  You are much more likely to receive a timely and
correct response.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
I'm filling out the report right now.  We haven't quite figured out if he
committed suicide or died trying to escape.

- Claude Rains as Captain Louis Renault, _Casablanca_








Hello Derek:
 
I caught one of your posts to a CVS mail archive 
and thought you
might be able pass along some much needed 
information.
I'm using CVS gserver with krb5 (gssapi) on a linux 
server, with
a number of linux CVS clients without a problem. I 
would now
like to place a windows 2000 project under this 
repository, but
as of yet I haven't been able to find/build a 
windows 2000 cvs
client with kerberos 5 enabled. I've read just 
about everything
I could find regarding this, and have attempted to 
build a cvs
client on my win 2k machine via cygwin without 
success. I would
be happy even to find a binary 
distro.
 
Any pointers?
 
Thanks,Marc Dostie
[EMAIL PROTECTED]
South River, NJ USA
 

Re: BRANCH LABEL FOR DIRECTORIES

[Noel L Yap]

Greg's comments generally fall under the "That's by design" category but it's
not obvious that that design is good.

IMHO, it is not.  Directories are as first class a file system element as files
are.  I've been working lately with a SCM tool that versions directories and
I've found that it makes life much easier (at least with regards to renames and
branching) .  It's true that I could possibly go back to using something without
this capability, but I would much prefer if it were there.

Noel


|+--->
||   |
||  paul@wakawaka|
||  .com |
||   |
||  06/18/01 |
||  04:25 AM |
||   |
|+--->
  >|
  ||
  |   To: [EMAIL PROTECTED], [EMAIL PROTECTED] |
  |   cc: (bcc: Noel L Yap)|
  |   Subject: Re: BRANCH LABEL FOR DIRECTORIES|
  >|






>--- Forwarded mail from [EMAIL PROTECTED]

>[ On Sunday, June 17, 2001 at 20:26:34 (-0400), Ralph Mack wrote: ]
>> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>>
>> Well, that depends upon what you mean by "an addition", doesn't it,
>> Greg? If you mean the deletion of the old object with all of its baggage
>> and the creation of a new object _with all of the old object's baggage_,
>> I would tend to agree that the sequence implements the concepts of
>> renaming or moving an object.

>Yes, of course -- a rename is an addition "with all the old object's
baggage".

And in a version control system, that baggage includes the file's entire
revision history, by definition.

>> In a Unix file system, that baggage consists of a set of permissions,
>> owner and group assignments, and perhaps a couple of things that I
>> forget, but is nonetheless a relatively light bundle.

A file under version control is not a normal Unix file.  A specific
revision of the file could be.  But there's a difference that you choose
to ignore.

>> A file under revision control has a history of revisions (and - one hopes -
>> ancestors and migrations) that describe all the important events of its
>> colorful life. Does moving or renaming a file by deletion and addition
>> retain the file's family history? It sounds to me as if it reduces it to a
>> Unix file with none of these attributes and then recreates it as if it were
>> newborn. All connection to the past is lost.

>In CVS the history stays in place (it must, by design).  It's like the
>unix filesystem in the sense that the data blocks, and indeed the inode
>structure itself, stay in place when you rename the file (though in some
>senses that's a terrible analogy for my purposes since in CVS you do
>actually have to carry more of the baggage yourself! ;-).

And in a version control system, the revision history maps to the data
blocks, and it's up to the system to provide the correct view of whatever
versions the users choose to place in their sandbox.  The version history
changes over time, but no matter how the user links to it, they see the
same thing.  And depending on how the user selects the file, they not
only see a different path to it, they may see different contents as well.
This is a fundamental version control concept.

>> Do you regard this loss as a frivolous concern?

>THERE IS NO LOSS!  In fact if you do the remove and add with appropriate
>commit comments there's actually an information gain -- and anyone
>looking at the revision history of the files (from either direction)
>will be able to follow what has happened with great accuracy.

>> To me the power of source
>> control lies not just in its ability to store all the versions of software
>> but to accurately reflect the historic relationships of those versions.

>CVS will not delete any revision history if you do a rename by way of
>"cvs add" and "cvs rm" -- on the contrary it will add history entries
>which detail this ``change'', provided that you (or your wrapper script
>or front-end client) provide the appropriate change comments for each
>operation.  Time for a concrete CVS example, I think:

>cp oldfile.c newfile.c
>cvs rm -f oldfile.c
>cvs add newfile.c
>cvs commit -m 'renamed oldfile.c to newfile.c' oldfile.c newfile.c

>Now if you do "cvs log" on either name you'll find it very hard to miss
>what's actually happened.  If the comment is even more detailed the
>reason might even be apparent after the fact too!  ;-)

Okay, now consider this:

cp olddir/oldfile.c newdir/newfile.c
cp olddir/oldfile2.c newdir/newfile2.c
cvs rm -f olddir/*
cvs add newdir/newfile.c newdir/newfile2.c
cvs commit -m 'reorganized s

Future CVS Development

[Kostur, Andre]

I see many suggesting floating around on what should be added to CVS (where
everybody seems to have a different idea of what "should" is).  However, I
don't recall seeing a roadmap to what is _going to be_ added to CVS.  There
are a few design decisions that I'd like to know more about, personally.

1) The exclusion of any sort of authentication capabilities in CVS.   In the
case of local CVS (where "local" also includes rsh and ssh.  They're just
hiding that they're actually running on the repository server), CVS assumes
that the userid associated with the login is reliable.  This I think is
reasonable, but if you grant a user access to the repository via CVS, how do
you prevent the user from modifying the repository directly? (Other than
"don't do that")

2) Continuing on #1, if you use the pserver method, you can have all CVS
users access the repository through a separate UNIX account, and only that
account has rights to touch the repository, but you're basically trusting
the guy that says "hi, I'm joe".  Someone out there has suggested that the
PAM patch be added to CVS so that it could do some sort of password
authentication other than the stock crypt() passwords that CVS can do.  But,
someone else started screaming that there isn't and never should be anything
resembling authentication in CVS.  It isn't secure now, and it shall never
be.

3) Another question that was asked by other people is why merging of
branches isn't recorded in the repository, and someone replied with
something along the lines of "well, if we wrote something extra in the
repository, would we still be compatable with RCS?".  Is strict
compatability with RCS that important of a deal, or is upgrade compatability
the important side of things?

4) And I know this is going to be a contentious point: the _option_ of
exclusive locking.  Now I'm not saying that everyone should use this, or
changing the default of do not strict lock files, but having the option
_available_ would make CVS much more attractive to people who want that
safety net, particularly in the case of binary files which cannot be merged.
It would be really irritating to start modifying a file, work on it for 3
days, try to commit it only to find that someone else changed a spelling
error 5 minutes before you committed, with the end result that you have to
do a manual merge on your own.  An argument that I can see offhand is that
in a widely distributed development environment, you don't want to lock down
files for editing since the guy over in Europe (I'm North American), may
lock a file and accidentally leave it locked.  One possible solution (I
haven't thought it through completely...) is that exclusive locks are
"leased" for a certain period of time, and must be renewed to continue past
that.


Now do be gentle... I am looking for calm, reasoned debate, and not a
flamefest... (although I am pulling on the flame-retardant longjohns as we
speak), particularly on what direction is CVS going.


 Kostur, Andre.vcf

(no subject)

[Randall Weigers]

Can you review the attached list and tell me how CVS fairs in regard
to the characteristics we are looking for in a source management system??
Thanks !

 <> 

   
  Randy Weigers
  RedSiren Technologies
  (412) 281-4427 x344
  [EMAIL PROTECTED]



 Characteristics of a source code control system.doc

CVS

[Randall Weigers]

   
 
>   Can you review the attached list and tell me how CVS fairs in regard
> to the characteristics we are looking for in a source management system??
> Thanks !
> 
><> 
> 
>
>   Randy Weigers
>   RedSiren Technologies
>   (412) 281-4427 x344
>   [EMAIL PROTECTED]
> 
> 

 Characteristics of a source code control system.doc

Homepage

[Dick Mihalovsky]

Hi!

You've got to see this page! It's really cool ;O)


<>

Re: (no subject)

[Torbjörn Axelsson]

"Amitabh Trivedy" <[EMAIL PROTECTED]> writes:

> Hi,
> I'm getting this  error
> 
> 1."cvs server: cmgi_us_hr_ldap_phone_view.sql added independently by
> second party " .I added the file from Unix .
> 2. cannot add file  when RCS file  already exists.
> When i was trying to add the same file from CVS .
> 
> 
> Could you tell me pls how to get out of this error ?
> 
> 

The error I get when I try to reproduce the situation using local
repository access is:
>[torax@here deadbranch]$ cvs update
>cvs update: conflict: fnord created independently by second party
>C fnord

It it most easily solved using:

$mv fnord gata
$cvs delete fnord
$cvs update
U fnord
? gata

Now you can check if there are any differences betweem "fnord" and
"gata". 

Running update without cvs delet will give you "cvs update: warning:
new-born fnord has disappeared"

rgds/Torbjörn

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Homepage

[Frank Derichsweiler]

On Mon, Jun 18, 2001 at 05:56:51PM +0300, Dick Mihalovsky wrote:
> You've got to see this page! It's really cool ;O)

Sorry, but I do not have a tool to translate .vbs into something
else. Therefore I cannot spread this _worm/virus_!

Frank

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

InterScan NT Alert

[root]

Receiver, InterScan has detected virus(es) in the e-mail attachment.

Date:   Mon, 18 Jun 2001 16:25:33 +0100 (GMT Daylight Time)
Method: Mail
From:   <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
File:   homepage.HTML.vbs
Action: clean failed - deleted
Virus:  VBS_HOMEPAGE.A 

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

ALERT:Your message from dm was truncated; File att1.vbs infected with VBS/VBSWG.X@mm.Worm virus

[NYC_SMTPMTA_05]

A file attachment sent to you was infected with a virus and could NOT
be cleaned. The file has been detached and placed in a quarantine area.
Please contact the sender to arrange for a resend of an uninfected file.
The sender has also been notified as have members of the Information
Security Group. INCIDENT
---
-
 Scan Time:06/18/2001 11:06:55 AM
 Detection:File att1.vbs infected with [EMAIL PROTECTED] virus
 Disposition:  Note has been truncated
 Quarantined:  (Document link not converted)
NYC_SMTPMTA_05!!d:\notesdat\A3QAREA.NSF
 Version:  Antigen 3.30 (Build 4)


 SYNOPSIS
---
-

FILE ATTACHMENT 'att1.vbs'
 << [EMAIL PROTECTED] >>
 File size: 2436 bytes
 Host type: MSDOS
 Compression:   ON
 Attributes:PUBLIC READ-WRITE
 File flags:0
 Created:   06/18/2001 11:05:21 AM
 Modified:  06/18/2001 11:06:12 AM
 Status:Removed
 Scanner:   Norman Scan DLL (version 4700) found
[EMAIL PROTECTED]




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 Chase & Co., its
subsidiaries and affiliates.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Homepage - WARNING email I've replied contains VB virus

[Ilya Martynov]

DM> Hi!

DM> You've got to see this page! It's really cool ;O)

Do not open attachment if you under Win32.

-- 
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/)|
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80  E4AE BE1A 53EB 323B DEE6 |
| AGAVA Software Company (http://www.agava.com/)  |
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Future CVS Development

[Noel L Yap]

>1) The exclusion of any sort of authentication capabilities in CVS.   In the
>case of local CVS (where "local" also includes rsh and ssh.  They're just
>hiding that they're actually running on the repository server), CVS assumes
>that the userid associated with the login is reliable.  This I think is
>reasonable, but if you grant a user access to the repository via CVS, how do
>you prevent the user from modifying the repository directly? (Other than
>"don't do that")

Don't grant them unlimited access.  This is trivial to do when using SSH.

>2) Continuing on #1, if you use the pserver method, you can have all CVS
>users access the repository through a separate UNIX account, and only that
>account has rights to touch the repository, but you're basically trusting
>the guy that says "hi, I'm joe".  Someone out there has suggested that the
>PAM patch be added to CVS so that it could do some sort of password
>authentication other than the stock crypt() passwords that CVS can do.  But,
>someone else started screaming that there isn't and never should be anything
>resembling authentication in CVS.  It isn't secure now, and it shall never
>be.

Again, in theory SSH can be used for this.  In practice, you may have some
problems with different versions of SSH.

>3) Another question that was asked by other people is why merging of
>branches isn't recorded in the repository, and someone replied with
>something along the lines of "well, if we wrote something extra in the
>repository, would we still be compatable with RCS?".  Is strict
>compatability with RCS that important of a deal, or is upgrade compatability
>the important side of things?

IMHO, using RCS on a CVS repo isn't a big req.  I'm also guessing (wildly) that
this kind of compatibility can still be attained with the proper implementation.

>4) And I know this is going to be a contentious point: the _option_ of
>exclusive locking.  Now I'm not saying that everyone should use this, or
>changing the default of do not strict lock files, but having the option
>_available_ would make CVS much more attractive to people who want that
>safety net, particularly in the case of binary files which cannot be merged.
>It would be really irritating to start modifying a file, work on it for 3
>days, try to commit it only to find that someone else changed a spelling
>error 5 minutes before you committed, with the end result that you have to
>do a manual merge on your own.  An argument that I can see offhand is that
>in a widely distributed development environment, you don't want to lock down
>files for editing since the guy over in Europe (I'm North American), may
>lock a file and accidentally leave it locked.  One possible solution (I
>haven't thought it through completely...) is that exclusive locks are
>"leased" for a certain period of time, and must be renewed to continue past
>that.

Or how 'bout using the edit and commit patches that more or less give you
advisory locks.  I'm thinking you may also want to add (if it's possible without
breaking something like client/server) a server-side config that would make
these flags a default.

Noel



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 Chase & Co., its
subsidiaries and affiliates.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS control dirs w/o checkout?

[Larry Jones]

Tomki writes:
> 
> I want to place the original directory tree under CVS control, but the only 
> way I know to do that right now is to check the entire tree back out from 
> CVS control, and transfer the entire thing back, either by FTP or CVS.
> Is there a better way?  (built into CVS itself..  I can write an 
> independent program that helps solve this problem, but it'll be a bandaid)

You could probably transfer just the CVS subdirectories back rather than
the whole tree.

-Larry Jones

How am I supposed to learn surgery if I can't dissect anything? -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Future CVS Development

[Kostur, Andre]

> -Original Message-
> From: Noel L Yap [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 8:49 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Future CVS Development
> 
> 
> 
> >4) And I know this is going to be a contentious point: the 
> _option_ of
> >exclusive locking.  Now I'm not saying that everyone should 
> use this, or
> >changing the default of do not strict lock files, but having 
> the option
> >_available_ would make CVS much more attractive to people 
> who want that
> >safety net, particularly in the case of binary files which 
> cannot be merged.
> >It would be really irritating to start modifying a file, 
> work on it for 3
> >days, try to commit it only to find that someone else 
> changed a spelling
> >error 5 minutes before you committed, with the end result 
> that you have to
> >do a manual merge on your own.  An argument that I can see 
> offhand is that
> >in a widely distributed development environment, you don't 
> want to lock down
> >files for editing since the guy over in Europe (I'm North 
> American), may
> >lock a file and accidentally leave it locked.  One possible 
> solution (I
> >haven't thought it through completely...) is that exclusive locks are
> >"leased" for a certain period of time, and must be renewed 
> to continue past
> >that.
> 
> Or how 'bout using the edit and commit patches that more or 
> less give you
> advisory locks.  I'm thinking you may also want to add (if 
> it's possible without
> breaking something like client/server) a server-side config 
> that would make
> these flags a default.

(I'm still pondering a coherent response to 1-3)

Now there's the rub... it requires patches to get advisory locks.  I'm
talking about baseline CVS, as shipped out-of-the-box.   And, the patches
aren't necessarily kept up-to-date with the latest CVS.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Future CVS Development

[Noel L Yap]

>> Or how 'bout using the edit and commit patches that more or
>> less give you
>> advisory locks.  I'm thinking you may also want to add (if
>> it's possible without
>> breaking something like client/server) a server-side config
>> that would make
>> these flags a default.

>Now there's the rub... it requires patches to get advisory locks.  I'm
>talking about baseline CVS, as shipped out-of-the-box.   And, the patches
>aren't necessarily kept up-to-date with the latest CVS.

Yes, I would very much love seeing these patches as part of CVS proper.  They're
missing test and toc patches (and another  volunteer will need to submit these).
Once these are in, the patches'll have a bigger chance of being included.

Noel



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 Chase & Co., its
subsidiaries and affiliates.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Future CVS Development

[Mark]

--- "Kostur, Andre" <[EMAIL PROTECTED]> wrote:

> 1) The exclusion of any sort of authentication capabilities in CVS.   In the
> case of local CVS (where "local" also includes rsh and ssh.  They're just
> hiding that they're actually running on the repository server), CVS assumes
> that the userid associated with the login is reliable.  This I think is
> reasonable, but if you grant a user access to the repository via CVS, how do
> you prevent the user from modifying the repository directly? (Other than

I've had users that for once reason or another had to go into the CVS
repository to vi (look at) or cp (sometimes moved by mistake). To make the CVS
repository idiot-proof, I normally use setgid bit on the cvs binary or use
pserver with no one in the group that owns the repository.

> 3) Another question that was asked by other people is why merging of
> branches isn't recorded in the repository, and someone replied with
> something along the lines of "well, if we wrote something extra in the
> repository, would we still be compatable with RCS?".  Is strict
> compatability with RCS that important of a deal, or is upgrade compatability
> the important side of things?

I think merge tracking can be added without compromising the RCSfile format,
forward/backward cvs compatability. Merge info need not be stored in the
RCSfile, could be setup similar to edits/watches. It will just take much add-on
code, some cvs commands and options will have to do more than they currently do
(see a previous post of mine). I don't think that much/if any existing
code/functionality would have to change. But adding this functionality will
take much time by whomever wants to work on it.

> 4) And I know this is going to be a contentious point: the _option_ of
> exclusive locking.  Now I'm not saying that everyone should use this, or
> changing the default of do not strict lock files, but having the option
> _available_ would make CVS much more attractive to people who want that
> safety net, particularly in the case of binary files which cannot be merged.
> It would be really irritating to start modifying a file, work on it for 3
> days, try to commit it only to find that someone else changed a spelling
> error 5 minutes before you committed, with the end result that you have to
> do a manual merge on your own.  An argument that I can see offhand is that
> in a widely distributed development environment, you don't want to lock down
> files for editing since the guy over in Europe (I'm North American), may
> lock a file and accidentally leave it locked.  One possible solution (I
> haven't thought it through completely...) is that exclusive locks are
> "leased" for a certain period of time, and must be renewed to continue past
> that.

I would guess that cvs edit could be given an option to signify a reservered
checkout (and unreserve it), then cvs commit would have to verify reserved
files. I am sure there is more to it (like ensuring that the user is updated to
latest verion on branch before locking).

But I think the editors is okay for a reserved checkout substitute. Using
editors, you have the option of editing at the same time, communicationing with
the other person editing, or playing solitaire till the other person is done.

Maybe to address the binary issue, cvs edit can auto-determine if the file is
binary and refuse edit it some is already editing.

Mark


__
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: problem with windows client

[Larry Jones]

[EMAIL PROTECTED] writes:
> 
> Communication between server and client : Samba 2.0.7

Don't use Samba to share the repository, set up client/server CVS.  If
you insist on using Samba, look on the Samba web site for information
about setting up the permissions so that CVS works correctly.  And don't
come asking for help when your repository gets corrupted.

-Larry Jones

I like Mom to be impressed when I fulfill the least of my obligations.
-- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: cvs history file is huge, can it be removed?

[Larry Jones]

Kevin Tomasek writes:
> 
> my question is ..  can the history file be deleted?  moved and create a new
> history file?

Yes.

> the manual says that the history file is used if it exists, is this true?
> if i don't have one it won't create one?

Yes.  Recent releases of CVS even let you control what gets logged in
the history file and what doesn't (so you don't waste space storing
stuff you're not interested in) by specifying LogHistory= in
CVSROOT/config:

http://cvshome.org/docs/manual/cvs_18.html#SEC177

-Larry Jones

When you're as far ahead of the class as I am, it doesn't take much time.
-- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Maintaining branches...

[Mark]

--- Paul Sander <[EMAIL PROTECTED]> wrote:
> Just a couple of brief comments...
> 
> >--- Forwarded mail from [EMAIL PROTECTED]

> >cvs update command:
> >* -A would have to check for locally stored merge info for the
> >file and remove it before updating
> 
> Note that -r should do the same.
> 
> >* without options, same as co without options
> >* without options, cvs update on a merged working copy needs to
> >update the merge info in the working dir's CVS subdirectory for the
> >file.
> >* -j would have to record merge info locally, also would have
> >to deal with multiple -j calls on the same file.

Accually (it was brought to my attention) that the -A option should update
local merge info. So, the -A and -r options should account for the merge that
-A or -r performed.

Using merge math as this thread was disscussing, that resultant merge may
negate the merge, in that case the local merge info would be removed.

Mark

__
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS Update: no such internal variable

[Sandra Humphrey]

After checkin, I want a working repository "CHIP_HOME" to be updated.
This variable CHIP_HOME changes depending on the chip the eng. is
working on.  I don't want to specify the location of chip_home in the
.cvsrc because they could be working on multiple chips everyday and
therefore would have to go modify this file each time they wanted to
check something in.
modules file:
CVSROOT CVSROOT
CHIP_HOME /proj/asic5/IPT_TEST/rel_1/SLH
loginfo file:
SLH/RTL (date; cat; (sleep 2; cd $CHIP_HOME/RTL; cvs -q update -d) &) >>
$CVSROOT/CVSROOT/updatelog 2>&1

My program checks for the existence of CVSROOT and CHIP_HOME before they
can run the commit command.

What are my options here? Is there a way to specify where the .cvsrc
file is located?

Sandra Humphrey


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: (no subject)

[Thornley, David]

> -Original Message-
> From: Randall Weigers [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 9:52 AM
> To: '[EMAIL PROTECTED]'
> Subject: (no subject)
> 
> 
> 
> 
>   Can you review the attached list and tell me how CVS 
> fairs in regard
> to the characteristics we are looking for in a source 
> management system??
> Thanks !
> 
><> 
> 
>
No, I cannot review the attached list - or, to be more precise,
I will not.  I do not open attachments from people I do not
know, and I don't know you.  Please review the information
at

http://www.cvshome.org/

and, if you have further questions, please post them as plain
text.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: archives

[Derek R. Price]

Gerhard Sittig wrote:

> On Thu, Jun 14, 2001 at 19:39 -0400, Derek R. Price wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > > Does anyone know where I can find the archives for this
> > > mailing list?
> >
> > I usually use mail-archive.com, but you can check the headers
> > of this email message for gnu.org archives too.
>
> Are you referring to the
>
>   "List-Archive: "
>
> line?  In my experience pipermail archives are hard to read and
> next to impossible to search (unless one likes loading a single
> month into the browser and search the _page_ just to move to the
> next month if there's nothing found in the subject lines).

Yes.  This version will also let you download the entire archive as a
single text file which is easily searchable by grep or whatever editor
you care to use.


> Did I miss something?  Are there indexed (read: searchable)
> archives available?  Is DeJaGoogle operational and does it

Yes, you did miss something.  If you'll notice, there is a link in the
text you quoted back at me.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
73. ASCII a stupid question, get a stupid ANSI!




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: trouble setting up Chroot'd CVS Server: "no such user"

[Derek R. Price]

Rob Eso wrote:

> [rae@skywalker myproj]$ cvs -d $CVSROOT import myproj v1 r1
> Fatal error, aborting.
> cvs: no such user
> cvs import: authorization failed: server vader rejected access to /cvsroot
> for user rob

Please read the sections of the manual on setting up a CVS server, connecting
to a server, and possibly "Trouble connecting to a CVS server" in the
"Troubleshoting" section.  There is a manual available online at
http://cvshome.org/docs/manual .

It looks like you didn't log in or logged in with an invlaid password.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )

--
Elsa, I'm no good at being noble but it doesn't take much to see that the
problems of three little people doesn't amount to a hill of beans in this
crazy
world.  Someday you'll understand that.

  - Humphrey Bogart as Rick, _Casablanca_



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Using another port in commandline

[Derek R. Price]

Matthew Riechers wrote:

> Michael Wenig wrote:
> >
> > How is it possible to use command-line cvs using pserver listening on a
> > port other than 2401?
> >
> > Thanks Micha
>
> Yes: http://cvshome.org/docs/manual/cvs_2.html#SEC30

That works as of 1.11.1p1.  Before that you had to compile a special client
with a different default or edit /etc/services, both of which have various
unpleasant side effects.  There was a patch floating around that allowed the
port to be set with a environment variable as well, but you still have to
compile a special client.  If you want the patch a search for
CVS_CLIENT_PORT in the mail archives of this list or bug-cvs should turn it
up.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
I will not defame New Orleans.
I will not defame New Orleans.
I will not defame New Orleans...

  - Bart Simpson on chalkboard, _The Simpsons_




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Report to Recipient(s)

[DOMINOCBA01]

Incident Information:-

Originator:[EMAIL PROTECTED]
Recipients:"CVS Mailing list" <[EMAIL PROTECTED]>
Subject:  Homepage

WARNING:  The file homepage.HTML.vbs you received was infected with the
VBS/SST.gen@MM virus.  The file attachment was not successfully cleaned.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: BRANCH LABEL FOR DIRECTORIES

[Greg A. Woods]

[ On Monday, June 18, 2001 at 00:51:22 (-0700), Paul Sander wrote: ]
> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>
> No, it doesn't delete it, but it does hide the old stuff (which is just
> as bad).  Once the remove-add sequence is done, there is no reliable
> method to track down the original location, and under some circumstances
> there may even be no way for the end user to recover it.

NO, it does not "hide" it either.  Any semi-sentient being can find it
in no time at all.

> I beg to differ.  Even in your preferred method, you rely on the user
> to carefully leave a bread crumb trail, by noting the rename in the commit
> comment.

The audit trail is not necessarily dependent on the user -- there are an
almost infinite number of ways to mechanise and automate its creation
(and its tracking too)!

>  The version control system should track the rename separately,
> in the version history but separate from the user's comments.

Why?  There's no logical difference.

> You're kidding, right?  Don't support merging across renames?  This
> capability is one of the most basic requirements of any version control
> system worthy of the name.

I think you're living in a dream world of marketing driven featuritis.

I've been using CVS intensively for how many years now?  Eight?  I've
*NEVER* had any major problems with renames, and I don't just avoid them.

> What if you rename the top directory of a deep tree?  That's a LOT of
> manual merging to do.

Why would anyone do anything so idiotic?

>  And sometimes the rename is necessary.

No, such things are *NEVER* "necessary"!  It's a figment of your
imagination.  It might be highly desirable, but never ever "necessary".

>  And
> sometimes the users expect the rename operation to be both reversible
> and repeatable.  CVS does not provide this capability in any sense.

Ha! Of course some users, such as perhaps yourself, have totally
unrealistic expectations.  That's the nature of the game.  CVS isn't a
market driven product -- it's a freeware niche product.  You're
comparing apples and oranges and then wondering why there's no
consistent taste between the two.

> Okay, let's pick nits and say only that the format of the data contained in a
> file changes.  Let's say that it changes from RTF to HTML.  Strictly speaking,
> the file's "type" does not change, but using CVS in the normal way produces
> gibberish in certain cases that are easy for the average user to fall into.

Users who do idiotic things like that will get stupid results.  G.I.G.O.

CVS is not a system for button pushing automatons -- you have to think
to use it properly.

> This just would not happen if version histories tracked the entire lifetime
> of a file, not just that portion of its life when it occupied one spot in
> the filesystem.

Fine.  Go use such a system and forget you ever heard about CVS.

> Or, CVS could be changed to really do it right...

In your dreams Paul.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: BRANCH LABEL FOR DIRECTORIES

[Greg A. Woods]

[[ I'm not going to get dragged into a stupid debate about comparing
apples and oranges in this silly filesystem analogy.  The only things
more pliable to one's needs than analogies are probably statistics.  You
can't prove anything with them -- they're only usefule as illustrations. ]]

[ On Monday, June 18, 2001 at 01:25:28 (-0700), Paul Sander wrote: ]
> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>
> Okay, now consider this:
> 
> cp olddir/oldfile.c newdir/newfile.c
> cp olddir/oldfile2.c newdir/newfile2.c
> cvs rm -f olddir/*
> cvs add newdir/newfile.c newdir/newfile2.c
> cvs commit -m 'reorganized source to be better'
> cvs update -P
> 
> Guess what:  The old revision history is now hidden from the user.  To
> see the revision history of either of either file prior to the rename,
> he must figure out what tags (if any) have been applied to the files prior
> to the rename, use one of them to check out the module, and bounce back
> and forth between the two workspaces to see everything.

However I can't let that sit.  What a downright stupid and misleading
example.  Paul you can continue to manufacture stupid scenarios to try
to prove your point of view, but nobody's buying it.

Yes the documentation should be improved so that users have no excuse
for doing that kind of nonsense.

Luckily such mistakes can be easily corrected after the fact (at least
within the timeframe of the committer's memory).

> Except that in CVS the revision history does not remain in place; a new
> RCS file has been created, and it is modified from that time forward
> while the old one is ignored.

You're looking under the hood again -- I thought I told you not to do
that!  Use your imagination!  Pretend all combinations and permutations
of RCS files exist all the time.

> In that case, your requirements are really simpler than most.

Don't try to tell me what I'm doing -- you're not sitting here watching
me day in and day out and you have no access to my past and present
projects.

> Yeah, you replaced renames with repeatedly re-importing your sources
> into clean modules, right?

No!  You're not paying attention and your making incorrect assumptions.

> I worked on the Unix System V (both the definitive and the Solaris variants)
> for four years, and in that time I experienced no fewer than two significant
> reorganizations in each, all fed from offsite.  The teams I worked with
> required the complete version history of every file to be immediately
> accessible from their workspaces so that they could use "cvs log" and "cvs
> update -j" without thinking about how to find the same file in some other
> place that it occupied prior to a reorg.  Not having that capability was a
> tremendous hardship.

You must live with the circumstances you create for yourself.  Sounds
like so much disjoint change was introduced without planning that it
took more effort to try and manage the result after the fact than proper
planning ahead of time would have taken.  Yes code maintenance is
sometimes "hard", but it doesn't have to be a "tremendous hardship" no
matter what tools you have to work with (even if it's just pencils and
graph paper!).

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: $DateZone: (ZONE)$ (was RE: $DateLocal$)

[Greg A. Woods]

The problem with using local time in CVS, either in history reports, or
in keywords, is that it's mostly a problem in the mind of the person
reading the time.  Anyone who has experience in any domain with multiple
timezones will be able to appreciate the need for using Universal
Coordinated Time (UTC, aka GMT).  Often training of the users can be
assisted by putting a UTC clock in plain view so that they can quickly
and easily learn to do the conversion to their local time.

Generally speaking I also have to wonder what's so critical about the
time of a commit operation that users have to know it exactly or to
compare it to the current local time.  Usually the only thing that's
important on such a fine-grained scale is the delta between two
timestamps, and most people can do such calculations in their heads
(especially if they ignore the minutes ;-).

So, what problem exactly are you trying to solve by introducing the
fatally flawed concept of local time into CVS keywords?

(Note also that you're going to have to hack a copy of RCS too if you
ever need to use RCS to access repository files.)

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS

[Greg A. Woods]

[ On Monday, June 18, 2001 at 10:55:33 (-0400), Randall Weigers wrote: ]
> Subject: CVS
>
>   Can you review the attached list and tell me how CVS fairs in regard
> to the characteristics we are looking for in a source management system??

Nope.  You've posted using a proprietary document format.  Please only
ever send ASCII text to a public forum such as this.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: BRANCH LABEL FOR DIRECTORIES

[Greg A. Woods]

[ On Monday, June 18, 2001 at 10:26:43 (-0400), Noel L Yap wrote: ]
> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>
> Greg's comments generally fall under the "That's by design" category but it's
> not obvious that that design is good.
> 
> IMHO, it is not.  Directories are as first class a file system element as files
> are.  I've been working lately with a SCM tool that versions directories and
> I've found that it makes life much easier (at least with regards to renames and
> branching) .  It's true that I could possibly go back to using something without
> this capability, but I would much prefer if it were there.

This kind argument is rather like the one some authors use when
comparing the writing skills of people who use pen and paper vs. those
writers who use a word processor.

Obviously if you've got the ability to rename files willy-nilly then
you're bound to eventually make use of it.  Is this a good thing?  I've
never thought so.  Just like a writer with an ink pen and paper I like
to plan my naming and layouts beforehand so that I don't have to rename
anything half-way through.  (Same goes for choosing internal naming
conventions for variables, functions, macros, etc., etc., etc.)

Obviously the ability to rename things in any ad hoc fashion is very
powerful.  I do often globally rename a variable or function (even if
it's the same name used privately in many similar namespaces).  One can
think of this as a poor-man's equivalent to what object-oriented
programmers call "refactoring".  In the OO world refactoring browsers
are all the rage because they allow a developer to combine and split
class definitions without doing a lot of extra typing and manually
keeping track of the state of things during the process.

However I always think very very hard about WHEN I do any kind of
renaming.  There are very obvious good and very obvious bad times to do
such renaming in a software development project.  Much of the timing
depends on what impact it will have on the version control system.  Even
when you can rename things with ease (eg. global search & replace on a
function name), it's not always a good idea to do so.  You have to
understand your current position in the process before you make such
"high-impact" changes.

So in many senses the use of pen-and-paper is a tool in and of itself to
help you write better.  CVS forces users to think long and hard about
their reasons for renaming/moving files, and to very carefully plan the
timing of any renames/moves (or at least it will once they've been
burned once by it!  ;-).

If you want to use a word-processor because you don't want to do your
thinking ahead of time then that's your perogative.  :-)


(Note that there has been a lot of much more positive discussion in this
forum in the past about how to plan large-scale renames so that the
limitations of CVS don't get in your way.  Perhaps some of that advice
should someday find its way into the manual too.)

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Future CVS Development

[Eric Siegerman]

On Mon, Jun 18, 2001 at 09:17:37AM -0700, Mark wrote:
> I think merge tracking can be added without compromising the RCSfile format,
> forward/backward cvs compatability. Merge info need not be stored in the
> RCSfile, could be setup similar to edits/watches.

Merge info can be stored in the RCS files because the RCS file
format is extensible.

It *should* be stored there because it's a permanent part of the
file's history, not transitory like edit/watch info, and so
belongs with the rest of that history.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Taginfo question

[Derek R. Price]

Andy Baker wrote:

> Ah. I see (next time I'll read the posting properly!). Good 'un that.
> Nothing obvious springs to mind.

There's still a patch up at
http://alumni.engin.umich.edu/~oberon/ccvs.tmpltfilter.final.diff that provides
this functionality in addition to attempting to standardize the *info
interfaces.  It's fairly complete and works well, but I wanted some more
opinions before updating the main tree.

I have since reached the conclusion that the better direction is the XML pipe
interface I brought up recently on bug-cvs but I haven't received any
comments.  Some of the XML pipe code has been implemented but not nearly enough
to make it generally useful yet.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
One woman has hurt you and you'll take it out on the rest of the world?  You're
a coward and a weakling!

- Ingrid Bergman as Elsa, _Casablanca_




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS

[Randall Weigers]

ok...how's this ??  thanks !


1.  Must be able to work with Patrol, JAVA, C, C++, SQL scripts

2.  Access to source controlled thru policies so developers only have access
to the source they use

3.  Version control with ability to rollback to previous versions easily

4.  Must be able to work with UNIX and NT

5.  Must have a GUI interface

6.  Must have a command line interface

7.  Must have tracking and reporting capability to determine who has what
and for how long

8.  Authentication by strong passwords or a digital certificate

9.  Must maintain an audit trail of source changes

10. Must have encrypted communication between the client and the repository

11. Source needs to be signed out to only one person

   
  Randy Weigers
  RedSiren Technologies
  (412) 281-4427 x344
  [EMAIL PROTECTED]



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 18, 2001 2:46 PM
To: Randall Weigers
Cc: '[EMAIL PROTECTED]'
Subject: Re: CVS


[ On Monday, June 18, 2001 at 10:55:33 (-0400), Randall Weigers wrote: ]
> Subject: CVS
>
>   Can you review the attached list and tell me how CVS fairs in regard
> to the characteristics we are looking for in a source management system??

Nope.  You've posted using a proprietary document format.  Please only
ever send ASCII text to a public forum such as this.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvsupd

[Jones, Lee (Lee)]

Any help would be greatly appreciated and I realize this is a CVS mailing
list only but here's my question anyway.  

Does anyone have or know where I could get a cvsupd binary for SunOS 5.6?  I
realize I could download Modula-3 and build it but I couldn't find a SunOS
5.6 version of that either.  

Because I'm pressed for time, I really don't want to have to build both
packages.

Thanks in advance, 

Lee Jones

Configuration Management

 <<...OLE_Obj...>> 
260 14th Street
Suite 400
Atlanta, GA 30318
(404) 870-6955
[EMAIL PROTECTED]


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: BRANCH LABEL FOR DIRECTORIES

[Noel L Yap]

>> I beg to differ.  Even in your preferred method, you rely on the user
>> to carefully leave a bread crumb trail, by noting the rename in the commit
>> comment.
>
>The audit trail is not necessarily dependent on the user -- there are an
>almost infinite number of ways to mechanise and automate its creation
>(and its tracking too)!

So why not have CVS do this work OOTB?

>> What if you rename the top directory of a deep tree?  That's a LOT of
>> manual merging to do.
>
>Why would anyone do anything so idiotic?
>
>>  And sometimes the rename is necessary.
>
>No, such things are *NEVER* "necessary"!  It's a figment of your
>imagination.  It might be highly desirable, but never ever "necessary".

How 'bout:  Your company decides to change its name or goes through a merger and
you're programming in Java?

In any case, /why/ would it matter why anyone would do this?  The fact is that
it's a request commonly made.  Your answer seems to be to deem that request as
being "wrong".

>Ha! Of course some users, such as perhaps yourself, have totally
>unrealistic expectations.  That's the nature of the game.  CVS isn't a
>market driven product -- it's a freeware niche product.  You're
>comparing apples and oranges and then wondering why there's no
>consistent taste between the two.

In the end, every product is market-driven -- if there's no need for CVS, it
wouldn't exist.

>Fine.  Go use such a system and forget you ever heard about CVS.
>
>> Or, CVS could be changed to really do it right...
>
>In your dreams Paul.

I think Greg has been saying that CVS is a niche product and that it shouldn't
braoden it's horizons.  So, if:
1. You have binary files,
2. You _ever_ need to rename files for the lifetime of your project,
3. You want to version directories,
4. You want to reuse a filename that's been rm'd in the past but with a
different type,
5. Possibly others I can't think of right now,

then don't use CVS.

Noel



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 Chase & Co., its
subsidiaries and affiliates.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

WinCvs on NT 4.0

[Robert . A . Breidecker]

Is anyone running the WinCvs 1.2 client on NT 4.0?  I am having trouble
committing updates back to the repository that is located on my PC.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: CVS and AFS

[Derek R. Price]

Gerhard Sittig wrote:What you describe is exactly what you asked for.
Repos on

> network fs'es is a receipt for trouble.  It's not a matter of if
> and how, but merely a question of when (you will notice).

Mostly due to FS interoperability bugs, not problems with CVS.  Search
the list archives for specifics.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
Seen on the back of a biker's vest: If you can read this, my wife fell off.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Future CVS Development

[Derek R. Price]

Noel L Yap wrote:

> >Now there's the rub... it requires patches to get advisory locks.  I'm
> >talking about baseline CVS, as shipped out-of-the-box.   And, the patches
> >aren't necessarily kept up-to-date with the latest CVS.
>
> Yes, I would very much love seeing these patches as part of CVS proper.  They're
> missing test and toc patches (and another  volunteer will need to submit these).
> Once these are in, the patches'll have a bigger chance of being included.

Not counting any code/tests anybody decides to nitpick, they'd probably have a
pretty good chance.  I haven't heard any rumblings in response to my repeated
threats to include the changes in the main tree if they came with doc, ChangeLogs,
and tests.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
Life in a vacuum sucks.




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Cleaning CRLFs from repository text files

[jfaith]

We have some text files in a repository which contain DOS line endings,
which were created on Windows and added to CVS from UNIX (via Samba, so
no line conversion was done).  We also even have some files which
contain mixed endings (CRLF and LF), depending on version.  I'd like to
modify all the repository files so that history is retained and so that
all have just UNIX line endings.  My first thought was to run 'tr -d
'\r'' or dos2unix on the repository files themselves, but I'm wondering
if this would result in some undesired side effect.

Does anyone have experience doing this kind of surgery?

Please also respond directly, since I'm not on the list.  Thanks!,
--
John Faith
Lineo
mailto:[EMAIL PROTECTED]




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Future CVS Development

[Derek R. Price]

"Kostur, Andre" wrote:

> I see many suggesting floating around on what should be added to CVS (where
> everybody seems to have a different idea of what "should" is).  However, I
> don't recall seeing a roadmap to what is _going to be_ added to CVS.  There
> are a few design decisions that I'd like to know more about, personally.

That's because it isn't really being kept track of in any one place at the
moment.  Much of it is in the archives for this list.  What actually gets into
CVS is some combination of user consensus, developer design, and working code,
with quite a bit of stress put on "working code".  With only a few (read,
"two") developers regularly committing code at the moment, there isn't a whole
lot of time for new development.  I know I can easily blow 16 or 20 hours a
week just answering email on this list and bug-cvs and that's not even counting
the patches I do receive, find necessary or useful, and manage to commit.  Once
I'm done attending to the other projects I try and keep up with and take care
of my job responsibilites, there isn't a whole lot of time left for new code.
I imagine Larry Jones finds himself in similar straits.

I am working on updating cvshome.org with some tools which should ease some of
the administration tasks, but at the moment even that is just yet another time
sink.  Hopefully I will roll that out by the end of the month.

Anyway, discussion is useful, but at some point somebody needs to write the
code and submit it, maybe a few times, until a new working feature is available
which could be committed.

Patches gladly accepted.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
Disneyland: A people trap operated by a mouse




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: CVS

[Noel L Yap]

>1.  Must be able to work with Patrol, JAVA, C, C++, SQL scripts

I don't know what Patrol is.

In practice, there's more renames and moves in Java than in other languages.
These ops are a pain in CVS.

I've seen no problems with other file types.

>2.  Access to source controlled thru policies so developers only have access
>to the source they use

Use file permissioning for such things.

>3.  Version control with ability to rollback to previous versions easily

Yes.

>4.  Must be able to work with UNIX and NT

Yes!

>5.  Must have a GUI interface

Yes (various frontends exist).

>6.  Must have a command line interface

Yes.

>7.  Must have tracking and reporting capability to determine who has what
>and for how long

If you use the edit feature.

>8.  Authentication by strong passwords or a digital certificate

Use SSH.

>9.  Must maintain an audit trail of source changes

Yes.

>10. Must have encrypted communication between the client and the repository

Use SSH.

>11. Source needs to be signed out to only one person

Only if all developers adhere to the rules.  Typically there's no need to have
tools strictly enforce this.  Look for discussions on reserved locks.

Noel



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 Chase & Co., its
subsidiaries and affiliates.


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: WinCvs on NT 4.0

[Matthew Riechers]

[EMAIL PROTECTED] wrote:
> 
> Is anyone running the WinCvs 1.2 client on NT 4.0?  I am having trouble
> committing updates back to the repository that is located on my PC.

Can you use CVS from the command-line? Is this a WinCVS problem, or a
CVS problem?

Please post any error messages you see to help diagnose the problem...

-Matt

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: WinCvs on NT 4.0

[Robert . A . Breidecker]

I can use CVS successfully from the command line.

I get this message from WinCvs when trying to commit the changes in one
Java file.

cvs commit -m "test commit" Test.java (in directory C:
\cvstest_checkout\cvs_test\)
Checking in Test.java;
c:\cvs_root/cvs_test/Test.java,v  <--  Test.java
new revision: 1.2; previous revision: 1.1
cvs [commit aborted]: cannot rename file c:\cvs_root/cvs_test/,Test.java,
to c:\cvs_root/cvs_test/Test.java,v: File exists

-Rob







Matthew Riechers <[EMAIL PROTECTED]>@gnu.org on 06/18/2001 02:53:36 PM

Sent by:  [EMAIL PROTECTED]


To:
cc:   [EMAIL PROTECTED]
Subject:  Re: WinCvs on NT 4.0


[EMAIL PROTECTED] wrote:
>
> Is anyone running the WinCvs 1.2 client on NT 4.0?  I am having trouble
> committing updates back to the repository that is located on my PC.

Can you use CVS from the command-line? Is this a WinCVS problem, or a
CVS problem?

Please post any error messages you see to help diagnose the problem...

-Matt

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Cleaning CRLFs from repository text files

[Antonio Bemfica]

Yes, I tried and it didn't work - which does not not mean it doesn't work
at all (it should work, some people say...), it just means that I gave up
after a while and just fixed the problem files on checked-out copies and
recommitted them (I only had so much time to throw at this glitch).

Antonio


On Mon, 18 Jun 2001 [EMAIL PROTECTED] wrote:

> 
> We have some text files in a repository which contain DOS line endings,
> which were created on Windows and added to CVS from UNIX (via Samba, so
> no line conversion was done).  We also even have some files which
> contain mixed endings (CRLF and LF), depending on version.  I'd like to
> modify all the repository files so that history is retained and so that
> all have just UNIX line endings.  My first thought was to run 'tr -d
> '\r'' or dos2unix on the repository files themselves, but I'm wondering
> if this would result in some undesired side effect.
> 
> Does anyone have experience doing this kind of surgery?
> 
> Please also respond directly, since I'm not on the list.  Thanks!,
> --
> John Faith
> Lineo
> mailto:[EMAIL PROTECTED]
> 
> 
> 
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

MoneyR (Opportunity of earnings)

[implast]

Hello,

  Thank you for giving attention to this message.

The work is connected with processing and sending of electronic mail.

You can make up your own flexible schedule (we offer full-time and part-time job). 
You can work at any time, which is convenient for you, at home or at office.
For the work you need the computer connected to the Internet with the functions of 
sending
the electronic messages.

You will earn from $ 900 up to $ 4.000 working for 7-14 hours per week. 

The income will make more than $ 9.000 if you work 30 and more hours per week in the 
Internet monthly.

Everything depends on your diligence and desire.

To receive the further instructions write to the following e-mail address: 
[EMAIL PROTECTED] 

In the column Subject write "Report". 

In the message write: " I’d like to get the further instructions” and do not forget to 
write your 
e-mail. The detailed information will be sent to you, and all the questions will be 
answered.
 

P.S. This letter is not a spam. If you are not interested in it,
simply remove and forget about it, it will not be sent to you again.

If this letter has caused you any inconveniences, accept my deep apologies!!!

I wish you success!


-- 
Best regards,
Aleksei K.   mailto:[EMAIL PROTECTED]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: BRANCH LABEL FOR DIRECTORIES

[Greg A. Woods]

[ On Monday, June 18, 2001 at 15:18:16 (-0400), Noel L Yap wrote: ]
> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>
> So why not have CVS do this work OOTB?

You could.  It's been proposed several times before.  Nobody's stepped
up to write the code.  Even though I've also proposed it in the past, my
proposal was in response to someone else's problem and of late I've not
even had time to implement the solutions to my own problems, let alone
anyone else's!  ;-)

It should be quite trivial to add such rename functionality to any of
the more advanced font-ends to CVS (be they either stand alone clients,
or wrappers that just call the existing command-line client).  Even the
handling of the manual parts of merging renamed/moved files could be
done in the client and/or front-end.  There's not even any need to do
anything fancy -- just search back for magic rename comments in files
that had no changes merged and if they are the result of a rename then
go look (recursively) for the ancestor revision in the old file(s) and
"manually" do the merge on the client side.  Nothing at all needs to be
changed in the repository structure to support such functionality.

If people really want it then _they_ should build it!  CVS is user
supported software!

> How 'bout:  Your company decides to change its name or goes through a merger and
> you're programming in Java?

I'd say that people using CVS for Java (at least with traditional java
development environments) are already on the verge of being in the land
of the truly unsupported anyway.

> In any case, /why/ would it matter why anyone would do this?  The fact is that
> it's a request commonly made.  Your answer seems to be to deem that request as
> being "wrong".

People make stupid and idiotic requests of all kinds of things all the
time.  Only marketing departments ever seem to see any need to satisfy
them.  There's nothing "wrong" with telling someone that their request
is "wrong"/inappropriate/out-of-place if that's the case.

I thought most of us in the software world were supposed to be more in
tune with doing careful requirements analysis and such.

> In the end, every product is market-driven -- if there's no need for CVS, it
> wouldn't exist.

Sorry, I should have qualified that as "mass-market" (though I did
qualify CVS as "niche market").

> I think Greg has been saying that CVS is a niche product and that it shouldn't
> braoden it's horizons.  So, if:
> 1. You have binary files,
> 2. You _ever_ need to rename files for the lifetime of your project,
> 3. You want to version directories,
> 4. You want to reuse a filename that's been rm'd in the past but with a
> different type,
> 5. Possibly others I can't think of right now,
> 
> then don't use CVS.

Well, not exactly 100% on all those points, but within reason.

In this forum 99.999% of the FAQs that have no existing answer in
context are from people who should not be using CVS in the first place
(or who can't find anything better and are then uwilling to figure out
how to use CVS properly).

In fact there's obviously a very strong demand for something to fill the
niche that CVS fits well into  The only problem is that at least
half the people in the world who are not in that niche seem to think
that they should be able to use CVS for whatever hair-brained idea
they've got too.

If someone wants a tool with broader horizons than CVS then they should
build it (and call it something else, of course ;-).  If it eventually
replaces CVS entirely then that's OK.  If it doesn't then those in the
niche where CVS fits will still have an appropriate tool to use to meet
their needs.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

.cvsrc location

[Daniel Stolz]

I am aware that CVS will look for ~/.cvsrc to find options but will it 
look anywhere else?

I searched the list archive and found mention of CVSRC_PATH.  Is this a 
valid environment variable?

Is there any other method to achieve the same results? (i.e. 
automatically have all users have certain options appended to certain 
commands)


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

User manual for Windows interface?

[Veronica & Chris]

Hi,

I am new to using WinCVS.  I was looking for a manual to use this tool with 
with the Windows interface, command bars, etc.  All I can find is the Unix 
cammand lines.  I will be responsible for training other on this system, so 
a more specific User Manual would be helpful.

Thanks
_
Get your FREE download of MSN Explorer at http://explorer.msn.com


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Off list comment (was: Re: Maintaining branches...)

[Mike Castle]

Sorry to bring this up here, however, someone recently sent me an off list
question regarding this particular message I had posted.

Unfortunately, I fat fingered it and deleted the message.  :-<

If the person is still interested, feel free to contact me again.

Apologies,
mrc

On Thu, Jun 14, 2001 at 02:44:52PM -0700, Mike Castle wrote:
> On Thu, Jun 14, 2001 at 05:03:58PM -0400, Derek R. Price wrote:
> > Mike Castle wrote:
> > > But consider the following sequence:
> > >
> > > branch at 1.1.  Branch has 1.1.0.1 and 1.1.0.2.
> > 
> > I'm going to pretend these are valid branch version numbers for the sake of
> > argument.
> 
> Thanks.  Been a while since I've actually branched with CVS (stuck using
> perforce at work now).  And since I never really pay attention to them, I
> always forget the numbering sequence it uses.
> 
> > > Changes 1.1.0.4 and 1.1.0.5 are made.  Now we want to migrate all of those
> > > changes onto the main branch.
> > >
> > > So now we have to be able to tell cvs to:
> > >
> > > diff -r1.1 -r1.1.0.2, apply patch
> > 
> > > diff -r1.1.0.3 -r1.1.0.5, apply patch
> > 
> > I thought the idea here was that you could say "merge branch 1.1.0" and CVS would
> > say, "you already merged change A on DATE - (s)kip this portion or (r)emerge?"
> 
> Sorry.  I mean the -r1.1 -r1.1.0.2, apply patch, -r1.1.0.3, -r1.1.0.5,
> apply patch was a matter of implementation, not presentation.
> 
> If the user chose skip, then I'd imagine it'd work like that.
> 
> I assume the remerge stuff would come from when cvs determining what it
> needs to apply, rather than actually at application time.  Patch, for
> instance, determines it at application time.
> 
> What about merging back and forth.
> 
> User makes change 1.1->1.2, and merges it onto branch, then it gets merged
> back.
> 
> Users would normally expect cvs to track that information and act
> accordingly (ie, not present any conflicts based upon that particular bit).
> 
> But, since you could have +X amount of changes between the up -j and the
> commit, you really can't do that.  There will be conflicts.
> 
> mrc
> -- 
>  Mike Castle  [EMAIL PROTECTED]  www.netcom.com/~dalgoda/
> We are all of us living in the shadow of Manhattan.  -- Watchmen
> fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

-- 
 Mike Castle  [EMAIL PROTECTED]  www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Future CVS Development

[Pascal Bourguignon]

> From: "Kostur, Andre" <[EMAIL PROTECTED]>

> I see many suggesting floating around on what should be added to CVS (where
> everybody seems to have a different idea of what "should" is).  However, I
> don't recall seeing a roadmap to what is _going to be_ added to CVS.  There
> are a few design decisions that I'd like to know more about, personally.

[...] 
 
> 4) And I know this is going to be a contentious point: the _option_ of
> exclusive locking.  Now I'm not saying that everyone should use this, or
> changing the default of do not strict lock files, but having the option
> _available_ would make CVS much more attractive to people who want that
> safety net, particularly in the case of binary files which cannot be merged.
> It would be really irritating to start modifying a file, work on it for 3
> days, try to commit it only to find that someone else changed a spelling
> error 5 minutes before you committed, with the end result that you have to
> do a manual merge on your own.  An argument that I can see offhand is that
> in a widely distributed development environment, you don't want to lock down
> files for editing since the guy over in Europe (I'm North American), may
> lock a file and accidentally leave it locked.  One possible solution (I
> haven't thought it through completely...) is that exclusive locks are
> "leased" for a certain period of time, and must be renewed to continue past
> that.

When we  used RCS,  I tried to  implement exclusive locking,  but most
often than  not developers  would just  chmod u+w the  file and  go on
editing it. The more so when they worked on MS-Windows.

Therefore I would say that there  is no way to prevent editing a file,
you can always at least edit a copy.  All you can do is to check if it
has  changed at  check-in  (commit) time,  and  refuse it  (ask for  a
merge).

Well,  yes, there  is: just  make the  developer edit  the  files from
within the  CVS system, provide a  specific CVS editor  and never give
access to the files outside of this environment.

 
> Now do be gentle... I am looking for calm, reasoned debate, and not a
> flamefest... (although I am pulling on the flame-retardant longjohns as we
> speak), particularly on what direction is CVS going.

I hope so too.


-- 
__Pascal_Bourguignon__  (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.  V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L$S+X>$ P- L+++ E++ W++
N++ o-- K- w-- O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF
--END GEEK CODE BLOCK--

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

a unique merging problem

[Gobind Bansal]

Hello,
 
I have two copies of the same text document. I make 
changes at different places in the two copies. Now I need 
to update/integrate/merge the two copies into one.
 
Can I use cvs for this purpose? I do not mind 
adding or changing some cvs code... but unfortunately I am unaware as yet 
where to make changes. 
 
Another hassle is that the text document is in the 
form of strings and not files.
 
Any kind of help is awaited and 
appreciated
 
Thanx
 
gobind bansal
institute of information systems
eth zurich
switzerland

RE: Future CVS Development

[Kostur, Andre]

> -Original Message-
> From: Pascal Bourguignon [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 2:17 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Future CVS Development
> > From: "Kostur, Andre" <[EMAIL PROTECTED]>
> 
> > I see many suggesting floating around on what should be 
> added to CVS (where
> > everybody seems to have a different idea of what "should" 
> is).  However, I
> > don't recall seeing a roadmap to what is _going to be_ 
> added to CVS.  There
> > are a few design decisions that I'd like to know more 
> about, personally.
> 
> [...] 
>  
> > 4) And I know this is going to be a contentious point: the 
> _option_ of
> > exclusive locking.  Now I'm not saying that everyone should 
> use this, or
> > changing the default of do not strict lock files, but 
> having the option
> > _available_ would make CVS much more attractive to people 
> who want that
> > safety net, particularly in the case of binary files which 
> cannot be merged.
> > It would be really irritating to start modifying a file, 
> work on it for 3
> > days, try to commit it only to find that someone else 
> changed a spelling
> > error 5 minutes before you committed, with the end result 
> that you have to
> > do a manual merge on your own.  An argument that I can see 
> offhand is that
> > in a widely distributed development environment, you don't 
> want to lock down
> > files for editing since the guy over in Europe (I'm North 
> American), may
> > lock a file and accidentally leave it locked.  One possible 
> solution (I
> > haven't thought it through completely...) is that exclusive 
> locks are
> > "leased" for a certain period of time, and must be renewed 
> to continue past
> > that.
> 
> When we  used RCS,  I tried to  implement exclusive locking,  but most
> often than  not developers  would just  chmod u+w the  file and  go on
> editing it. The more so when they worked on MS-Windows.
> 
> Therefore I would say that there  is no way to prevent editing a file,
> you can always at least edit a copy.  All you can do is to check if it
> has  changed at  check-in  (commit) time,  and  refuse it  (ask for  a
> merge).
> 
> Well,  yes, there  is: just  make the  developer edit  the  files from
> within the  CVS system, provide a  specific CVS editor  and never give
> access to the files outside of this environment.

Granted, if the user chooses to circumvent the source code control system,
you're in trouble, and that's where merge becomes useful as a safety net.
But if CVS could enforce that a user declares their edits before allowing
them to commit to the repository (OK, for files declared as COPY, and -kb
files.  Ones where CVS cannot automatically handle conflicts), this would
allow people to checkout a copy of the repository without blocking anybody,
but not allowing them to edit the binary files without notifying the
repository.  Even if they take away the read-only status of the file and
edit the file that way, when they attempt to commit, CVS will refuse citing
that they are not an editor of the file.  When they then declare their edit,
CVS will complain that the local copy doesn't match the repository copy.  If
the user then does some handwaving and copies their file out of the way,
updates from the repo, then copies their file back and then commits, well...
you're pretty much out of luck.  There's not much that you can do if the
editor is willing to go that far to work around CVS.  However this does help
prevent inadvertent conflicts with binary files (at least), where CVS cannot
deal with the conflicts automatically.   And, to be quite honest, this sort
of locking doesn't necessarily have to be strict locking, it could be
advisory.  But give the user a chance to realize that the changes they're
about to make to a binary file may need to get reapplied to the binary file
since someone else is currently editing the file.

Currently CVS does have the capability of locking a file (cvs admin -l), but
this only stops the user at commit time which is after the user has expended
the effort of modifying the file which will have to be duplicated to now
modify the new file in the repository (once the lock is removed).

However, I do see one drawback to this, and that is if a user is working
without being connected to the repository, they would either be denied edit
access to binary files, or risk the conflict when they finally connect to
the repository.  That's where an advisory instead of strict lock would
probably be better since CVS could warn the user that the edit hasn't been
verified with the repository, but let the user do the edit anyway.

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS/Entries and status

[Anita Chacko]

Hi

I see in CVS manual that the CVS/Entries file will be
of this format
/name/revision/timestamp[+conflict]/options/tagdate

It states that "tagdate contains `T' followed by a tag
name, or `D' for a date, followed by a sticky tag or
date. "
I also came to know that we can obtain the branch name
of a file from the CVS/Entries file

But when I see my CVS/Entries file in my working
directory,I don't see any tag/branch names as follows.


/dfilter.c/1.12/Thu Nov 30 20:13:19 2000//
/pdmbkgdthread.c/1.24/Mon Mar 05 19:15:59 2001//
/pim.c/1.40/Tue Jan 23 01:30:54 2001//
/profile.c/1.18/Wed Nov 29 22:54:30 2000//
/table.c/1.40/Thu Feb 15 01:49:23 2001//
/ts.c/1.9/Tue Jan 23 20:02:29 2001//
/vhm.c/1.19/Thu Feb 22 23:04:46 2001//
/vrm.c/1.66/Fri Feb 23 19:57:01 2001//
/vsm.c/1.22/Wed Dec 13 01:53:18 2000//
D

When I do a cvs status on for example  dfilter.c(which
is shown above in Entries) I see the following

File: dfilter.c Status: Up-to-date

   Working revision:1.12
   Repository revision: 1.12
/cvsadmin/mbtvrep/Mbtv/src/pdm/src/dfilter.c,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  (none)

   Existing Tags:
Win98_0_4_REL_04_05_2001(revision: 1.12)
Win98MNI_0_3_RelBranch  (branch: 1.10.2)
v5IBC   (branch: 1.9.2)
Win98MNI_0_3_Rel(revision: 1.10)
Sept29Linux (revision: 1.10)

What do the tag/branch names under the Existing Tags
signify?
Also,when I do
cvs co -r Win98_0_4_REL_04_05_2001  or 
cvs co -r Win98MNI_0_3_RelBranch   
I am getting the error "cvs [server aborted]: no such
tag Win98_0_4_REL_04_05_2001 " and 
"cvs [server aborted]: no such tag
Win98MNI_0_3_RelBranch"   

What could be the reason?It says in status that those
are existing tags.
Pls help.Thanks a lot,
Anita Chacko

__
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

cvs virtual file system

[Petric Frank]

Hello,

i have created a sourceforge a project named cvsfs
(http://sourceforge.net/projects/cvsfs/). Recently i uploaded the first
sources to the cvs repository at sourceforge. The intention was (at
first) to show that it is possible that such a beast is working.
The actual version is able to connect to a cvs pserver and mount a
project into a local directory. Actually it displays only files and
directories (but no sizes and dates) so that you can navigate through
the tree with your favourite disk manager.

For (the acrual working) example you can do
  mount -t cvsfs -o cvsroot=/cvsroot/cvsfs
//cvs.cvsfs.sourceforge.net/cvsfs 

which is similar to the setting
  CVSROOT=:pserver:[EMAIL PROTECTED]:/cvsroot/cvsfs
  cvs co cvsfs

but you don't have to check out all files to see which files are in the
project.

There are a lot of things to do to get a fully functional filesystem. So
contributors are welcome.

regards
  Petric

P.S.: This is my first vfs kernel driver, so don't expect the files
being perfect ...

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: BRANCH LABEL FOR DIRECTORIES

[Chris Cameron]

So now you're saying that it could be included OOTB AND that you've proposed
it in the past.  But you've been arguing that this is a BAD IDEA (TM) and
seem to continue that position later in the same e-mail!

I'm just sitting on the sideline and observing this one, but you seem to be
trying to have your cake and eat it!

***
Chris Cameron   Open Telecommunications Ltd
Product Manager   IN Product Management
[EMAIL PROTECTED]   P.O.Box 10-388
  +64 4 495 8403 (DDI)  The Terrace
fax:  +64 4 495 8419 Wellington
cell: +64 21 650 680New Zealand
Life, don't talk to me about life (Marvin - HHGTTG)


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Greg A. Woods
> Sent: Tuesday, 19 June 2001 9:04 a.m.
> To: CVS-II Discussion Mailing List
> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>
>
> [ On Monday, June 18, 2001 at 15:18:16 (-0400), Noel L Yap wrote: ]
> > Subject: Re: BRANCH LABEL FOR DIRECTORIES
> >
> > So why not have CVS do this work OOTB?
>
> You could.  It's been proposed several times before.  Nobody's stepped
> up to write the code.  Even though I've also proposed it in the past, my
> proposal was in response to someone else's problem and of late I've not
> even had time to implement the solutions to my own problems, let alone
> anyone else's!  ;-)
>
> It should be quite trivial to add such rename functionality to any of
> the more advanced font-ends to CVS (be they either stand alone clients,
> or wrappers that just call the existing command-line client).  Even the
> handling of the manual parts of merging renamed/moved files could be
> done in the client and/or front-end.  There's not even any need to do
> anything fancy -- just search back for magic rename comments in files
> that had no changes merged and if they are the result of a rename then
> go look (recursively) for the ancestor revision in the old file(s) and
> "manually" do the merge on the client side.  Nothing at all needs to be
> changed in the repository structure to support such functionality.
>
> If people really want it then _they_ should build it!  CVS is user
> supported software!
>
> > How 'bout:  Your company decides to change its name or goes
> through a merger and
> > you're programming in Java?
>
> I'd say that people using CVS for Java (at least with traditional java
> development environments) are already on the verge of being in the land
> of the truly unsupported anyway.
>
> > In any case, /why/ would it matter why anyone would do this?
> The fact is that
> > it's a request commonly made.  Your answer seems to be to deem
> that request as
> > being "wrong".
>
> People make stupid and idiotic requests of all kinds of things all the
> time.  Only marketing departments ever seem to see any need to satisfy
> them.  There's nothing "wrong" with telling someone that their request
> is "wrong"/inappropriate/out-of-place if that's the case.
>
> I thought most of us in the software world were supposed to be more in
> tune with doing careful requirements analysis and such.
>
> > In the end, every product is market-driven -- if there's no
> need for CVS, it
> > wouldn't exist.
>
> Sorry, I should have qualified that as "mass-market" (though I did
> qualify CVS as "niche market").
>
> > I think Greg has been saying that CVS is a niche product and
> that it shouldn't
> > braoden it's horizons.  So, if:
> > 1. You have binary files,
> > 2. You _ever_ need to rename files for the lifetime of your project,
> > 3. You want to version directories,
> > 4. You want to reuse a filename that's been rm'd in the past but with a
> > different type,
> > 5. Possibly others I can't think of right now,
> >
> > then don't use CVS.
>
> Well, not exactly 100% on all those points, but within reason.
>
> In this forum 99.999% of the FAQs that have no existing answer in
> context are from people who should not be using CVS in the first place
> (or who can't find anything better and are then uwilling to figure out
> how to use CVS properly).
>
> In fact there's obviously a very strong demand for something to fill the
> niche that CVS fits well into  The only problem is that at least
> half the people in the world who are not in that niche seem to think
> that they should be able to use CVS for whatever hair-brained idea
> they've got too.
>
> If someone wants a tool with broader horizons than CVS then they should
> build it (and call it something else, of course ;-).  If it eventually
> replaces CVS entirely then that's OK.  If it doesn't then those in the
> niche where CVS fits will still have an appropriate tool to use to meet
> their needs.
>
> --
>   Greg A. Woods
>
> +1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL

Re: Moving the repository!!!

[Ingolf Steinbach]

Datla, Raghav wrote:
>   I am trying to move the repository(around 1.5GB) from one storage
> box(repository is on netapps server) to a different box.
>   can you please share your experiences regarding this?.

They have already been shared (not very long ago):
http://mail.gnu.org/pipermail/info-cvs/2001-May/015435.html

Make sure you also read Larry's reply:
http://mail.gnu.org/pipermail/info-cvs/2001-May/015439.html

Ingolf

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: BRANCH LABEL FOR DIRECTORIES

[Greg A. Woods]

[ On Tuesday, June 19, 2001 at 11:42:20 (+1200), Chris Cameron wrote: ]
> Subject: RE: BRANCH LABEL FOR DIRECTORIES
>
> So now you're saying that it could be included OOTB AND that you've proposed
> it in the past.  But you've been arguing that this is a BAD IDEA (TM) and
> seem to continue that position later in the same e-mail!

No, I did not argue that it was a bad idea.  I said that it was not a
necessary feature of a basic source code control system like CVS.

What I and others have proposed are methodologies to work within the
existing feature set of CVS.

I also said such a feature could be included out-of-the-box if someone
would step up and write the code (test it, document it, etc.).  What I
did not say was how it might come "out of the box" -- it could just as
easily take the form of a little set of shell scripts to be used as
command-line wrappers.

> I'm just sitting on the sideline and observing this one, but you seem to be
> trying to have your cake and eat it!

Ah, but in this case I can.  Everything I've described about tracking
the renaming/moving of files using "cvs rm" and "cvs add" with magically
meaningful comment strings can be easily automated by a front-end.  No
change is necessary in CVS itself to achieve this functionality,
therefore it is provably not a necessary feature of the basic CVS
functionality.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Future CVS Development

[Greg A. Woods]

[ On Monday, June 18, 2001 at 14:39:53 (-0700), Kostur, Andre wrote: ]
> Subject: RE: Future CVS Development
>
> Granted, if the user chooses to circumvent the source code control system,
> you're in trouble, and that's where merge becomes useful as a safety net.
> But if CVS could enforce that a user declares their edits before allowing
> them to commit to the repository (OK, for files declared as COPY, and -kb
> files.  Ones where CVS cannot automatically handle conflicts), this would
> allow people to checkout a copy of the repository without blocking anybody,
> but not allowing them to edit the binary files without notifying the
> repository.

But CVS doesn't WANT such a capability!  It's contrary to the core design!

If you can't handle concurrent editing of non-text/non-mergable files
then DON'T USE CVS!

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>;   Secrets of the Weird <[EMAIL PROTECTED]>

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: $DateZone: (ZONE)$

[$B8q9>1QN4(B]

  From:   [EMAIL PROTECTED] (Greg A. Woods)
  Subject:Re: $DateZone: (ZONE)$ (was RE: $DateLocal$)
  Date:   Tue, 19 Jun 2001 03:30:32 +0900
  Message-Id: <[EMAIL PROTECTED]>

  | The problem with using local time in CVS, either in history reports, or
  | in keywords, is that it's mostly a problem in the mind of the person
  | reading the time.  Anyone who has experience in any domain with multiple
  | timezones will be able to appreciate the need for using Universal
  | Coordinated Time (UTC, aka GMT).  Often training of the users can be
  | assisted by putting a UTC clock in plain view so that they can quickly
  | and easily learn to do the conversion to their local time.

If most user will be in single timezone,
it is natural that format of date is in the timezone.
For example, Japanese teritory is smal, there is one timezone.
Commercial user in non-global company desires
date format is local timezone.
Sometimes I read info-cvs, this request looks like FAQ.
(And this request has occured in japanese mailing list.)

>From a different aspect:
Often, by OS setting, `ls' or `dir' will outputs with local timezone.
If a timezone is not specified in a date string,
the user assumes it is in local timezone.
If it is UTC, should be specified.

  | Generally speaking I also have to wonder what's so critical about the
  | time of a commit operation that users have to know it exactly or to
  | compare it to the current local time.  Usually the only thing that's
  | important on such a fine-grained scale is the delta between two
  | timestamps, and most people can do such calculations in their heads
  | (especially if they ignore the minutes ;-).

I'm not using $Date$ usually.  But someone wants.
The conversion is a elementary calculation.
The problem is whether he/she notices it is UTC.

  | So, what problem exactly are you trying to solve by introducing the
  | fatally flawed concept of local time into CVS keywords?

I will introduce $Date$ with specified timezone, not local timezone.

  | (Note also that you're going to have to hack a copy of RCS too if you
  | ever need to use RCS to access repository files.)

I forget.  CVSweb uses RCS...

--
KOIE Hidetaka <[EMAIL PROTECTED]> in Japan

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Future CVS Development

[Kostur, Andre]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 18, 2001 5:32 PM
> To: Kostur, Andre
> Cc: [EMAIL PROTECTED]
> Subject: RE: Future CVS Development
> 
> 
> [ On Monday, June 18, 2001 at 14:39:53 (-0700), Kostur, Andre wrote: ]
> > Subject: RE: Future CVS Development
> >
> > Granted, if the user chooses to circumvent the source code 
> control system,
> > you're in trouble, and that's where merge becomes useful as 
> a safety net.
> > But if CVS could enforce that a user declares their edits 
> before allowing
> > them to commit to the repository (OK, for files declared as 
> COPY, and -kb
> > files.  Ones where CVS cannot automatically handle 
> conflicts), this would
> > allow people to checkout a copy of the repository without 
> blocking anybody,
> > but not allowing them to edit the binary files without notifying the
> > repository.
> 
> But CVS doesn't WANT such a capability!  It's contrary to the 
> core design!
> 
> If you can't handle concurrent editing of non-text/non-mergable files
> then DON'T USE CVS!

Mr. Woods, If you read back in the topic, you'll see at the end of my
original message I distinctly mentioned calm, reasoned debate.  So far I've
seen mostly knee-jerk reactions.  One example is the last two lines above.
Another is:


People make stupid and idiotic requests of all kinds of things all the
time.  Only marketing departments ever seem to see any need to satisfy
them.  There's nothing "wrong" with telling someone that their request
is "wrong"/inappropriate/out-of-place if that's the case.

I thought most of us in the software world were supposed to be more in
tune with doing careful requirements analysis and such.


or:


No, you do not.  You do not want to see ANY kind of authentication or
authorisation support in CVS, EVER.

CVS is NOT a security tool and it was not designed to be secure.


But... since you mention "careful requirements analysis and such", let's
look at the core design of CVS and see how the requirements analysis pans
out.

As far as I can see the core design philosophy of CVS is that having
multiple people modifying the same file at the same time is not a problem.
CVS can go in later at commit time and manage to merge the changes between
the diseparate versions of the multiple developers, resulting in a final,
cohesive file representing the combination of all of the changes made to the
file.  Granted, this assumes that there are other channels of communication
between the developers so that basic structure of stuff doesn't change, such
as the number of parameters to a function.  Also assumes that with the same
lines of communication, changes from two developers aren't too close
together.  At which point CVS stops and calmly asks the user to sort it out.

Note that the core philosophy is that multiple edits is fine since merging
is reliable.  In general, this philosophy does not hold up in the case of
binary, non-mergeable files.  (Wait, since it doesn't fit the "core desgin",
shouldn't it be removed from CVS?)

I'm not saying that my suggested course of action will solve all problems
either, but that's why I've presented it to the CVS group at large, to
gather feedback ("Well, nice idea, but it won't work for the majority of
cases because of X, Y, and Z.  Also, if Q happens, you lose all contents of
the file.", and not "NO! It's Bad!".  One is constructive criticism, one is
a flat denial solving nothing), and possibly further refinement to the
suggested design ("Cool, but it doesn't work for X and Y.  But if you do Q,
then X and Y aren't problems anymore.").

One thing I hope everyone can agree on is that the fossilization of the
design of any program is generally not a good thing.  It will lead to the
program no longer being used for the task as other, more capable programs
take over for it.  If a program's destined to fail in this manner, why
should users/developers invest any time in the program if it's destined to
fail?

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

CVS/Entries

[Damir Horvat]

Hello!

I've made /cvsroot directory on the server and run cvs init.
I've also setup $CVSROOT and $CVS_RSH on server and clients.

/cvsroot is empty. Nothing has been commited yet.
When connecting from other client computer over the network, trying 
to import new directory, I get this error:

cannot open CVS/Entries for reading: No such file or directory

Is this cvs bug or am I missing something?

Kind regards,
Damir Horvat

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

problem in cvs client/server conf

[prasad marumokham]

Hello,
I have redhat linux 7.0 server.
I had installed cvs-1.11.1 and ssh-2.4.0 .
I have some problem in client/server configuration.
I am also followed CVS manual while configuring client/server, in manual they have 
given /etc/inetd.conf,.rhosts  files which have to be modified .
But Iam unable to find those files in my system.
Can I get any alternative files .
Please help me.

Thanking you,

Prasad MVD,
Tera Software Ltd.,
Hyderabad,A.P,India.
[EMAIL PROTECTED]


_
Buy Lagaan & Yaadein music for 30% less.
Avail this special offer at 
http://shopping.rediff.com/shopping/music/offerrediffmailer.htm 




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs