Re: cvs branch version

[david]

> Hi,
> 
> I used 'cvs tag' to add a file to a branch. I then used 'cvs commit 
> -r... ' to check in a new version. It normally creates a subversion from 
> the version initially tagged. For example, I tag file 'A' version 1.1 
> with "release-patch". It creates a version 1.1.0.2 for the tag. When I 
> check in a new version to the branch, it creates a version 1.1.2.1. But 
> this time, I did not see any output from the command line after I 
> entered the  comments in vi. When I did a 'cvs log', I did not see any 
> subversion created.
>
Did you change the file before committing it?  CVS will not create a new
revision unless there are changes from the old one.
 
> If I do a 'cvs status' on the file, the sticky tag shows :
> Sticky Tag:  release-patche (branch: 1.1.2)
> 
> But I cannot see this revision with 'cvs log'. Can anyone explain what 
> happened?
>
Sure.  You now have the file in your working area as branch 1.1.2, but
since there is no change from the original version, the only revision is
1.1.  This revision is on both the trunk and the branch right now.  That's
what it looks like to me.

David H. Thornley| If you want my opinion, ask.
[EMAIL PROTECTED]   | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Renaming a branch

[David Leskovac]

>David Leskovac writes:
>> 
>> Okay. So, just to be clear, this is actually a 3-step process:
>> 1. Checkout branch:
>>cvs co -r  
>> 2. Rename from sandbox:
>>cd to root of module in sandbox
>>cvs admin -n newname:oldname
>> 3. Delete original tag name sandbox:
>>cd to root of module in sandbox
>>cvs tag -d oldname
>> 
>> Correct?
>
> Correct.  I strongly encourage you to verify that step 2 has worked
> correctly before you move on to step 3, though.  :-)

Thanks to all for the responses on this.

Last question(s):
If the "cvs admin -n" command renames branches why the need to delete
the original branch name? What happens if you don't delete the original name?

-Dave


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Renaming a branch

[David Leskovac]

>> Would this work for each branch to be renamed?:
>> cvs rtag -b -r   
>
> No, that creates a new branch off of the existing branch rather than
> renaming the existing branch.  You need to use admin -n instead.

Okay. So rather than the 2-step process I mentioned in my original post
where I would create a new branch from the original branch & then delete
the original branch, there is a way to simply rename the existing branch
with a "cvs admin -n" command? I looked at the syntax of "cvs admin" but
it is not clear to me how this can be achieved. Would someone please provide
an example?

Thanks,
-Dave


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Renaming a branch

[David Leskovac]

> You still need a 2-step process, you just use admin -n to create a new
> name for the existing branch rather than using tag -b to create a new
> branch:
>
>   cvs admin -n newname:oldname
>   cvs tag -d oldname
>
> (Note that there's no "radmin" command so you need to have a checked out
> working directory.)

Okay. So, just to be clear, this is actually a 3-step process:
1. Checkout branch:
   cvs co -r  
2. Rename from sandbox:
   cd to root of module in sandbox
   cvs admin -n newname:oldname
3. Delete original tag name sandbox:
   cd to root of module in sandbox
   cvs tag -d oldname

Correct?

-Dave


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Renaming a branch

[David Leskovac]

Hi,

Sorry for the basic question but I need to implement a new branch
naming scheme & want to make sure I am doing this correctly.

To start this process, I need to rename several existing branches.

Would this work for each branch to be renamed?:
cvs rtag -b -r   
cvs rtag -d 

I am aware of the -B argument to rtag. But, the version of cvs that
we use is so old (1.11.1p1) that it pre-dates that argument.

-Dave


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Continuous Integration with CVS

[David Leskovac]

> Is any one doing Continuous Integration with CVS ?  

Yes. We use CruiseControl 2.2.1

-Dave


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Nooby question: need help with setting CVSROOT="/usr/local/cvs-rep"

[David Leskovac]

> It's working just as designed.  :-)  Variables that stay
> around "permanently" only stay that way as long as you are
> logged in.  I suggest adding it to your .bashrc file in your
> home directory.  UNIX/Linux process that file every time a new
> terminal session is opened and will set it automatically at that
> time as a part of your profile setup. 

You may also want to consider adding the variable to:
/etc/profile or /etc/bashrc

to make $CVSROOT available to all users - if you have permission
to edit those files.

-Dave


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Idea for reducing disk IO on tagging operations

[Dr. David Alan Gilbert]

* Doug Lee ([EMAIL PROTECTED]) wrote:
> I followed this discussion only loosely and kept silent because I
> suspect someone will shoot me to pieces for the complaint I'm about to
> make, but now that we're to the stage of actual implementation, I
> guess I'd like to say this anyway...

Hey that's OK.

> I have reservations about any system that makes whitespace significant
> in a text file.  I can make an exception for indent levels, as used by
> Python, because these are visible and errors are obvious without
> resorting to odd tactics like hex editors, vi's :list command, etc.

Let me make it clear that this patch *in no way* makes whitespace
significant; in actual fact it only works because it isn't
significant.

What it does is put a glob of whitespace in when it is convenient;
nothing changes in the parsing or anything - so just like before
that whitespace is completely ignored.

The trick is that when it comes to add a tag it checks to see if there
is spare white space and if so overwrites it; if you removed
the white space or otherwise fettled with the file that is fine;
it won't perform the optimisation.

Indeed this means that an existing cvs client can quite happily
read a repository which has had my patch inflicted on it.

(The existing cvs code that rewrites the file will remove any
excess white space you added up there anyway.)

Dave
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Idea for reducing disk IO on tagging operations

[Dr. David Alan Gilbert]

Hi,
  Well, I've had a crack at implementing the optimisation; and attached
is a patch which seems to work - but there is at least one nasty
hack in it; more about that in a sec.

To enable it you need to add:
  TagOverwriteEnable=yes
to the config file in the CVSROOT; without that it should not
change behaviour in any way (except adding that as a commented
out option with warning to a newly created repository).

It won't give you any performance benefit on the first tag, but should
give something on subsequent tags.  I see some improvement (~15%)
but it is variable, on a large repository that doesn't fit in
memory on my home machine.

It is my first dig into the CVS code base, so I would appreciate
(gentle) comments.

Now some details;
  1) The real nasty hack; this is something that I hadn't thought
  of (and I don't think anyone else noticed?) in my original
  description; the permissions on the rcs files is read only
  so when I need to open them to overwrite I can't - this is a pain;
  this patch has a gratuitous (and obviously WRONG) hack in of
  chmod'ing it before the open - I'm open for any suggestions *if*
  there is a right way of doing this. (This was a pain because
  it was at the very last stage of the patch that I noticed this!).

  2) I don't currently create the dummy ,foo, locking file.

  3) I haven't written any docs yet.

  4) I needed to get a couple of values out of rcsbuf_getkey and
  have shoved them in globals for the moment; I was looking for a
  neater way that wouldn't mean changing all the callers.

  5) I'm worried about the right types to use for file offsets
  in a portable way. (Has anyone tried cvs with rcs files over 2GB?)

The patch is against 1.12.9 which is the version my debian happened to
have.

As I say, suggestions - and experiences welcome.

Dave
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/
diff -ur orig/cvs-1.12.9/ChangeLog cvs-1.12.9/ChangeLog
--- orig/cvs-1.12.9/ChangeLog   2004-06-09 15:52:32.0 +0100
+++ cvs-1.12.9/ChangeLog2005-03-24 23:43:48.0 +
@@ -1,3 +1,6 @@
+2005-03-24  Dave Gilbert <[EMAIL PROTECTED]>
+  * Added fast tagging mechanism; rcs.h/c, parseinfo.c,mkmodules.c
+
 2004-06-09  Derek Price  <[EMAIL PROTECTED]>
 
* NEWS: Note Stefan & Sebastian's security fixes.
diff -ur orig/cvs-1.12.9/src/admin.c cvs-1.12.9/src/admin.c
--- orig/cvs-1.12.9/src/admin.c 2004-03-22 15:37:34.0 +
+++ cvs-1.12.9/src/admin.c  2005-03-27 20:39:38.0 +0100
@@ -792,7 +792,7 @@
 || (rev = RCS_tag2rev (rcs, p))) /* tag2rev may exit */
{
RCS_check_tag (tag); /* exit if not a valid tag */
-   RCS_settag (rcs, tag, rev);
+   RCS_settag (rcs, tag, rev, NULL);
free (rev);
}
 else
diff -ur orig/cvs-1.12.9/src/commit.c cvs-1.12.9/src/commit.c
--- orig/cvs-1.12.9/src/commit.c2004-06-09 15:52:37.0 +0100
+++ cvs-1.12.9/src/commit.c 2005-03-27 20:39:45.0 +0100
@@ -2144,7 +2144,7 @@
head = RCS_getversion (rcs, NULL, NULL, 0, (int *) NULL);
magicrev = RCS_magicrev (rcs, head);
 
-   retcode = RCS_settag (rcs, tag, magicrev);
+   retcode = RCS_settag (rcs, tag, magicrev, NULL);
RCS_rewrite (rcs, NULL, NULL);
 
free (head);
diff -ur orig/cvs-1.12.9/src/import.c cvs-1.12.9/src/import.c
--- orig/cvs-1.12.9/src/import.c2004-04-27 22:08:40.0 +0100
+++ cvs-1.12.9/src/import.c 2005-03-27 20:39:59.0 +0100
@@ -770,7 +770,7 @@
 if (noexec)
return (0);
 
-if ((retcode = RCS_settag(rcs, vtag, vbranch)) != 0)
+if ((retcode = RCS_settag(rcs, vtag, vbranch, NULL)) != 0)
 {
ierrno = errno;
fperrmsg (logfp, 0, retcode == -1 ? ierrno : 0,
@@ -792,7 +792,7 @@
 vers = Version_TS (&finfo, NULL, vtag, NULL, 1, 0);
 for (i = 0; i < targc; i++)
 {
-   if ((retcode = RCS_settag (rcs, targv[i], vers->vn_rcs)) == 0)
+   if ((retcode = RCS_settag (rcs, targv[i], vers->vn_rcs, NULL)) == 0)
RCS_rewrite (rcs, NULL, NULL);
else
{
diff -ur orig/cvs-1.12.9/src/mkmodules.c cvs-1.12.9/src/mkmodules.c
--- orig/cvs-1.12.9/src/mkmodules.c 2004-05-29 05:48:52.0 +0100
+++ cvs-1.12.9/src/mkmodules.c  2005-03-24 23:43:38.0 +
@@ -349,6 +349,23 @@
 "# Be warned that these strings could be disabled in any new version of 
CVS.\n",
 "UseNewInfoFmtStrings=yes\n",
 #endif /* SUPPORT_OLD_INFO_FMT_STRINGS */
+"# Options relating to the Tag overwrit

Re: Idea for reducing disk IO on tagging operations

[Dr. David Alan Gilbert]

* Jim Hyslop ([EMAIL PROTECTED]) wrote:
> Dr. David Alan Gilbert wrote:
> >  2) I could do with a better under standing of the directory locks;
> >  pointers? I've read the top of lock.c but it still doesn't tell me
> >  enough; for example there seem to be multiple lock files used - but
> >  then surely the creation of them isn't atomic? Or is there one lock
> >  file used for both reading and writing?
> The locking process is explained in the manual, at 
> https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_2.html#SEC17

Thanks Jim for pointing me at that (I'd had a good search through
the FAQ rather than the manual).

(and to Paul - apologies if I misquoted in that last email)

OK; this convinces me that I don't need to worry about cvs reading
my file while it is being modified.  Together with the restriction
of me only performing my trick if the write is entirely within
a block then I feel reasonably safe.

I'm going to have a crack at making this optimisation and will
forward a copy here for discussion when I've done it.

Dave
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Idea for reducing disk IO on tagging operations

[Dr. David Alan Gilbert]

* Mark D. Baushke ([EMAIL PROTECTED]) wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Paul Sander <[EMAIL PROTECTED]> writes:
> 
> Actually, if you look closely, I believe that CVS will not do read-only
> RCS operations if a CVS write-lock exists for the directory. Of course,
> ViewCVS and CVSweb do it all the time as do many of the other add-ons.

I'm getting more worried about this one for 2 seperate reasons:
  1) There is talk of cvs -n for diff and the like which seems to
  suggest it ignores locks.
  2) I could do with a better under standing of the directory locks;
  pointers? I've read the top of lock.c but it still doesn't tell me
  enough; for example there seem to be multiple lock files used - but
  then surely the creation of them isn't atomic? Or is there one lock
  file used for both reading and writing?


> > There's also the interrupt issue:  Killing an update before it
> > completes leaves the RCS file corrupt.  You'd have to build in some
> > kind of crash recovery.  But RCS already has that by way of the comma
> > file, which can simply be deleted.  Other crash recovery algorithms
> > usually involve transaction logs that can be reversed and replayed, or
> > the creation of backup copies.  None of these are more efficient than
> > the existing RCS update protocol.
> 
> Agreed. This is a very big deal.

Actually I'm becoming less worried by this; I'm failing to see any way
that a single system call write() to a block not crossing a block
boundary could partially fail; but I'm up for suggestions.

Dave

 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Idea for reducing disk IO on tagging operations

[Dr. David Alan Gilbert]

* Mark D. Baushke ([EMAIL PROTECTED]) wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Dr. David Alan Gilbert <[EMAIL PROTECTED]> writes:
> > 
> > OK, if I create a dummy ",foo.c," before
> > modifying (or create a hardlink with that name
> > to foo.c,v ?) would that be sufficient?
> 
> I would say that it is likely necessary, but may
> not be sufficient.

Hmm ok.

> > Or perhaps create the ,foo,c, as I normally
> > would - but if I can use this overwrite trick on
> > the original then I just delete the ,foo.c,
> > file.
> 
> I am unclear how this lets you perform a speedup.

I only create the ,foo.c, file - I don't write anything into it; the
existence of the file is enough to act as the RCS lock; if I can do my
inplace modification then I delete this file after doing it, if not then
I proceed as normal and just write the ,foo.c, file and do the rename
as you normally would.

> > Is the problem that things are allowed to read
> > the original foo.c,v while you are creating the
> > new version?
> 
> I am given to understand that many of the
> anicillary tools that surround CVS make use of
> being able to read a consistent ,v file at all
> times.

This is very tricky; I don't think in our case we use any such tools
(we might have a cvs/web thing for browsing it, but this is probably
not critical); and as long I can guarentee what I do is safe as far
as CVS itself is concerned I think I'd be prepared to go for it as a
configurable mechanism.

> > So the issue is what happens if the interrupt
> > occurs as I'm overwriting the white space to add
> > a tag; hmm yes; 
> 
> Correct. Depending on the filesystem kind and the
> level of I/O, your rewrite could impact up to three
> fileblocks and the directory data.
> 
> > is it possible to guard against this by using a
> > single call to write(2) for that? 
> 
> Not for all possible filesystem types.
> 
> > Is that the problem you are thinking of?
> 
> Yes. Even worse things can happen in this regard
> if the filesystem is a 'stateless' one such as an
> NFS mounted directory (we keep advising folks
> against using them, but I know for a fact that
> they are still used).

OK, my conscience will let me carefully ignore NFS issues given the
pain it causes me elsewhere (and I make my mechanism switchable).
What happens if I only used the overwrite mechanism if
none of the characters being modified crossed a 512 (e.g.) byte
boundary offset in the file?  Since the spaces were actually
written in a previous operation we can assume that the space
is allocated and no allocation operation is going to happen
at this point (mumble filesystem journalling mumble!).

> > Sure, seperating the tagging data out is much
> > neater; but what I was looking for here was a
> > simple speed up which didn't require anything
> > extra and would be fully compatible with
> > existing tools.
> 
> And you are finding that existing tools torture
> the assumptions you are able to make about the CVS
> repository.

Nod; it is quite painful!

> FWIW: (In my personal experience) using a SAN
> solution for your repository storage allows you
> much better throughput for all write operations in
> the general case as the SAN can guarentee the
> writes are okay before the disk actually does it.

But when you throw a GB of writes at them in a short time from a tag
accross our whole repository they aren't going to be happy - they are
going to want to get rid of that backlog of write data ASAP.

> Optimizing for tagging does not seem very useful
> to me as we typically do not drop that many tags
> on our repository.

In the company I work for we are very tag heavy, but more importantly
it is the tagging that gets in peoples way and places the strain
on the write bandwidth of the discs/RAID.

Dave
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Idea for reducing disk IO on tagging operations

[Dr. David Alan Gilbert]

* Paul Sander ([EMAIL PROTECTED]) wrote:

Hi Paul,
  Thanks for the reply,

> Everything that Mark says is true.  I'll add that some shops optimize 
> their read operations under certain conditions, and such optimizations 
> would break if the RCS files are updated in-place.
> 
> What happens is that, if the version of every file can be identified in 
> advance (using version number, tag, or branch/timestamp pair) then they 
> can invoke RCS directly to fetch file versions, read metadata, and so 
> on.  This sidesteps CVS' overhead and can increase performance by as 

So are these tricks *never* performed by cvs itself? i.e. would my
trick (if I can solve the interrupted write case) be completely
safe with any use of cvs as long as you didn't access the files
externally?

Dave
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Idea for reducing disk IO on tagging operations

[Dr. David Alan Gilbert]

[Resend: I sent it with the wrong 'from' address - apologies
if you get both]

* Mark D. Baushke ([EMAIL PROTECTED]) wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 

Hi Mark,
  Thanks for your reply.

> Dr. David Alan Gilbert <[EMAIL PROTECTED]> writes:
> 
> > So - here are my questions/ideas - I'd appreciate comments to tell
> > me whether I'm on the right lines:
> >   1) As I understand it the tag data is the
> >   first of the 3 main data structures in the RCS
> >   file (tag, comments, diffs) and that when I do
> >   pretty much any CVS operation I rewrite the
> >   whole file - is this correct?
> 
> CVS write operations on a foo.c,v repository file
> will write ,foo.c, and then when the write
> operation is successful and without any errors, it
> does a rename (",foo.c,", "foo.c,v"); to make the
> new version the official version. While the
> ,foo.c, file exists, RCS commands will consider
> the file locked.
> 
> It is desirable to use RCS write semanitcs as many
> other tools out there (cf, ViewCVS) use RCS on the
> repository and want to obey RCS locking.

OK, if I create a dummy ",foo.c," before modifying (or create a hardlink
with that name to foo.c,v ?)  would that be sufficient?  Or perhaps create
the ,foo,c, as I normally would - but if I can use this overwrite trick
on the original then I just delete the ,foo.c, file.  Is the problem that
things are allowed to read the original foo.c,v while you are creating
the new version?

> be configured). So, yes, whitespace is mostly
> irelevent between sections.

Great.

> >   3) So the idea is that when I add a tag I add
> >   a bunch of white space after the tag (lets say
> >   1KB of spaces split into 64 byte lines or
> >   similar); when I come to add the next tag I
> >   check if there is plenty of white space, if
> >   there is then instead of rewriting the file I
> >   just overwrite the white space with my new tag
> >   data; if there is no space then as I rewrite
> >   the file I add another lump of white space.
> 
> This has the potential to more easily corrupt the
> RCS file if the operation is interrupted for any
> reason.

The act of rewriting adding extra space would be performed using the existing
mechanism (with just some extra add space created in RCS_rewrite);
so that can't be a problem.

So the issue is what happens if the interrupt occurs as I'm overwriting
the white space to add a tag; hmm yes; is it possible to guard against
this by using a single call to write(2) for that?  Is that the problem
you are thinking of?

> It would be more robust to enhance CVS to use an
> external database for tagging information instead
> of putting the tagging information into the RCS
> files directly than to rewrite parts of the RCS
> file and hope that the operation didn't corrupt
> the file along the way.

Sure, seperating the tagging data out is much neater; but what I was
looking for here was a simple speed up which didn't require anything
extra and would be fully compatible with existing tools.

> You may wish to consider looking at Meta-CVS as I
> believe that Kaz keeps a lot of the branching
> information outside of the RCS files already.
> 
> See http://users.footprints.net/~kaz/mcvs.html
> for more details on Meta-CVS.

If I was changing to another tool then I'd have a much larger set of
tools to consider (e.g.  subversion) but I'd rather stick with plain CVS
if I can - I've got clients on lots of (weird) OSs that work via pserver
and an infinite number of scripts built around CVS.

Thanks for the reply,

Dave
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Idea for reducing disk IO on tagging operations

[Dr. David Alan Gilbert]

Hi,
  I maintain a system that is used to hold a rather large
CVS repository (~1GB give or take) which could do with being faster.
Tagging in particular is slow and I don't think cpu or ram is the
issue (it is a dual xeon with 3GB of RAM).

My suspicion is that at least one of the problems is that when
a tag is added most of the rcs files are rewritten giving a sudden
large amount of data that must be written to disc.

So - here are my questions/ideas - I'd appreciate comments to tell
me whether I'm on the right lines:
  1) As I understand it the tag data is the first of the 3 main
  data structures in the RCS file (tag, comments, diffs) and that
  when I do pretty much any CVS operation I rewrite the whole file -
  is this correct?

  2) White space appears to be irrelevent in RCS files; so adding
  arbitrary amounts in between sections should leave files still
  fully compatible with existing RCS/cvs tools.

  3) So the idea is that when I add a tag I add a bunch of white
  space after the tag (lets say 1KB of spaces split into 64 byte
  lines or similar); when I come to add the next tag I check if
  there is plenty of white space, if there is then instead of
  rewriting the file I just overwrite the white space with my
  new tag data; if there is no space then as I rewrite the
  file I add another lump of white space.

  4) Whether dummy white space is added and how much is controlled
  by the existing size of the RCS file; so an RCS file that is only
  a few KB wont have any space added; that way this mechanism doesn't
  slow down/bloat small repositories.  The amount of white space might
  be chosen to align data structures with disk block boundaries.

  5) My main concern is to do with concurrency/consistency requirements;
  is the file rewrite essential to ensure consistency, or is the
  locking that is carried out sufficient?
  
Does this make sense?

Dave

 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: "cvs release" does not update the CVS/Entries(.log) file

[david . andersson]

Larry Jones writes:
> Reinstein, Shlomo writes:
> >
> > I would like to use "cvs release" to get rid of a sub-tree of my
project.
> > However, I noticed that "cvs release" does not update the
"CVS/Entries" (or
> > "CVS/Entries.log") file, which causes a problem later when I want
to run
> > other commands, like "cvs status", "cvs tag", etc.
>
> Indeed, that's a long-standing bug that's unfortunately difficult to
> fix.  The workaround is to just delete the directory from CVS/Entries
by
> hand.

If the sub-dir was deleted using "cvs remove " then issuing
the command "cvs update -d -P " will remove the sub-dir entry
from the "CVS/Entries" file.

If there exists files in the sub-dir in the repository but you simply
don't want the sub-dir in your working dir, then try referring a time
when the sub-dir didn't exist. In general 1980 almost nothing existed:
"cvs update -d -P -D 1980-01-01 ".

(Either way, it doesn't matter if you earlier have removed the sub-dir
using "cvs release" or "rm -r", or not.)

(The -P will remove the sub-dir in your working dir, if it exists and
becomes empty. It will not be removed if it contains changed or unknown
files. In that case be ware of sticky date if -D was used.)

(Tested in CVS version 1.10 and 1.11. Found out by trial and error so I
don't know if there is a better way.)

___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Renaming a file in the trunk but not in branches

[David Leskovac]

One additional question on this:
Is there any way to preserve history on the new file?

My understanding is that if I copy the ,v to ,v
on the server and then run the commands below on the client, then
this will affect the trunk as well as the branches. Is this true?

If true, is there any other way to rename a file in the trunk &
retain the history of the oldfile in the newfile while keeping the
oldfile intact in the branches?

Thanks,
-Dave

-Original Message-
From: Jim.Hyslop [mailto:[EMAIL PROTECTED]
Sent: Friday, March 11, 2005 10:33 AM
To: David Leskovac; info-cvs@gnu.org
Subject: RE: Renaming a file in the trunk but not in branches


David Leskovac wrote:
> Will the following commands work to rename a file in the
> trunk but retain the old file name in all its branches?:
> 
> cvs co 
> cvs remove -f 
> cvs add 
> cvs commit -m"Renamed  to "  
Yes, that will work fine.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. ( http://www.leitch.com )
Columnist, C/C++ Users Journal ( http://www.cuj.com/experts )


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Renaming a file in the trunk but not in branches

[David Leskovac]

Hi,

Will the following commands work to rename a file in the
trunk but retain the old file name in all its branches?:

cvs co 
cvs remove -f 
cvs add 
cvs commit -m"Renamed  to "  

Thanks,
-Dave


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Server times

[David A. Bartmess]

On Thursday 24 February 2005 11:33 pm, Guus Leeuw jr. wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:info-cvs-
> > [EMAIL PROTECTED] On Behalf Of David A. Bartmess
> > Sent: vendredi 25 février 2005 06:53
> >
> > On Thursday 24 February 2005 08:24 am, Jim.Hyslop wrote:
> > > rakesh mailgroups wrote:
> > > > does anyone know if the repository server having a different time
> > > > than local PCs will cause issues with CVS?
> > >
> > > None whatsoever. CVS was designed to be able to operate with
> >
> > workstations
> >
> > > in multiple time zones (unlike, say, Visual Source Safe). All times are
> > > converted to UTC before being stored in the repository.
> >
> > But if a local PC was used to work on files, having a current time at
> > checkin
> > of 11:30 MDT, and the server at time of checkin is 13:35 EDT, this could
> > seriously screw with any automation that relies on the datetime stamp to
> > know
> > if a build has already included that change (i.e., cruisecontrol).
>
> Uhm?
>
> EDT != UTC && MDT != UTC
>
> *All* CVS Client -> Server and Server -> Client communication is
> (virtually) done in UTC. Meaning, as Jim said, local PC uses MDT, talks to
> CVS server, and CVS server converts to UTC, and also CVS server uses UTC,
> talks to CVS client, and CVS client converts to MDT. The EDT settings of
> your server are totally unimportant within the CVS server!
>
> 
> We (as in previous job) used to manage a CVS repo in Germany, and access it
> from within the States. No problems in timing *ever* occurred.
> 

I was talking about the 5 minute difference in my example, though. Not in the 
timezone difference. Rakesh asked about a difference in "time". That could 
have weird consequences, depending on the usage on checkout...
-- 
David A. Bartmess
Software Configuration Manager / Sr. Software Developer
eDingo Enterprises
http://edingo.net
_
jSyncManager Development Team (http://www.jsyncmanager.org)
jSyncManager Email List
(https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel)
 
 But one should not forget that money can buy a bed but not sleep, 
 finery but not beauty, a house but not a home, 
 medicine but not health, luxuries but not culture, 
 sex but not love, and amusements but not happiness.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: CVS Server times

[David A. Bartmess]

On Thursday 24 February 2005 08:24 am, Jim.Hyslop wrote:
> rakesh mailgroups wrote:
> > does anyone know if the repository server having a different time than
> > local PCs will cause issues with CVS?
>
> None whatsoever. CVS was designed to be able to operate with workstations
> in multiple time zones (unlike, say, Visual Source Safe). All times are
> converted to UTC before being stored in the repository.

But if a local PC was used to work on files, having a current time at checkin 
of 11:30 MDT, and the server at time of checkin is 13:35 EDT, this could 
seriously screw with any automation that relies on the datetime stamp to know 
if a build has already included that change (i.e., cruisecontrol).

Just FYI...

-- 
David A. Bartmess
Software Configuration Manager / Sr. Software Developer
eDingo Enterprises
http://edingo.net
_
jSyncManager Development Team (http://www.jsyncmanager.org)
jSyncManager Email List
(https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel)
 
 But one should not forget that money can buy a bed but not sleep, 
 finery but not beauty, a house but not a home, 
 medicine but not health, luxuries but not culture, 
 sex but not love, and amusements but not happiness.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: Restricting use of 'cvs rtag' & 'cvs tag' commands [2nd try]

[David Leskovac]

> Install cvs in a different place than the version you are using.
>
> Make a script named cvs in the current location of cvs. That
> script should check the cvs commands vs. valid users. If
> everything is OK, then it should invoke the new cvs in the
> new place with the arguments passed to it.

This is an interesting idea.

> This won't protect you from truly malicious developers who
> invoke cvs directly from the new location, but you probably
> have already fired those people from your project. :-)

None of the developers are malicious. The problem came up
because on 3 separate occasions, a developer who is not
very familiar with CVS somehow deleted 3 active branches.
As to firing developers, that's out of my realm. I am just
a lowly release engineer. :-)

One person suggested an open source product called Sinis.
http://sinis.sourceforge.net/

This product intrigues me. Has anyone on this list used Sinis?

-Dave



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Restricting use of 'cvs rtag' & 'cvs tag' commands [2nd try]

[David Leskovac]

[I sent this msg 10 days ago & noone responded. So, I'm trying again.]

Hello,

We are currently using an ancient version of CVS (1.11.1p1) on a rather old 
Linux server (Red Hat 6). I intend to upgrade to CVS 1.11.19 & eventually 
upgrade the Linux OS. In the course of our CVS upgrade discussion we started 
discussing how to increase security with regards to CVS access. I am aware of 
the cvsacls script that provides fairly fine-grained permissions to do 
check-ins but is there also a way of restricting who is allowed to do certain 
cvs commands? In particular, we would like to restrict who can create/delete 
tags & branch tags. Is it possible to restrict 'cvs tag' & 'cvs rtag' on a user 
or group level?

Thanks,
-Dave


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: braches best usage

[David A. Bartmess]

What I've done in this scenario in the past is to create an "integration" 
branch. NOT a QA branch, but one which the developers only are allowed to 
merge to, just to check the viability of their changes. A cruisecontrol 
system runs a continuous build on the integration branch,  to do both of 1) 
test the build to make sure no one breaks it syntactically, and 2) run the 
junit or other automated tests to ensure they didn't break it logically.

This isn't much of an overhead, and if the developer does any testing at all 
on his box, using his copy of the integration branch, the results are almost 
always good to go to QA (merged to the QA branch for the next QA build).

Note that the developers should merge THEIR branch directly to the QA branch 
(or the SCM admin should) to avoid introducing non-tested code merged from 
other developers.

It's fairly simple to setup the scripts to allow them to do this without much 
hassle, and it makes for an even better chance at passing QA's testing if it 
goes through these steps. I've always been able to (after a proving period) 
convince the management it's worth a minor hassle on the developer and/or SCM 
to get this much done...

On Monday 21 February 2005 05:50 pm, bobby temper wrote:
> Hi,
>
> I have a point that confuses me about branches usage.
>
> We have developpers that want to isolate themselves from the trunk, by
> creating a branch.
>
> After that, the code needs to go to QA. This is where i'm confused: how can
> we make that code go to QA? If we merge the code from the branch to the
> trunk, before doing QA, what if that code cannot go to the next release?
>
> I was thinking of creating a QA branch, and have everyone wanting their
> code to be QAed needs to merge their code to that branch. But then again,
> this might create a little overwork..
>
> What's the best thing to do? I'm a bit lost...
>
> Best regards,
> Bobby
>
> _
> Express yourself instantly with MSN Messenger! Download today - it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>
>
> ___
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://lists.gnu.org/mailman/listinfo/info-cvs

-- 
David A. Bartmess
Software Configuration Manager / Sr. Software Developer
eDingo Enterprises
http://edingo.net
_
jSyncManager Development Team (http://www.jsyncmanager.org)
jSyncManager Email List
(https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel)
 
 But one should not forget that money can buy a bed but not sleep, 
 finery but not beauty, a house but not a home, 
 medicine but not health, luxuries but not culture, 
 sex but not love, and amusements but not happiness.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: jar files in cvs repository

[David A. Bartmess]

I'm not sure of the speeds, but it's a two-edged sword. Keeping full copies of 
everything bloats the database requirements for CVS, making the disk space an 
issue. And I couldn't say whether not using the "diff" to create deltas to 
keep instead would be faster or slower than checking in a full copy every 
time. But for source code, etc, I'd quickly say that checking in a full copy 
is a waste, since it's not that big usually, and the time differences would 
be minimal...

Maybe someone else has actually done timing on this?

On Monday 21 February 2005 12:39 am, Jesper Vad Kristensen wrote:
> David Bartmess wrote:
> >Used in the cvswrappers file, the -m gives the mode of the
> >file to the cvs
> >admin command, setting the mode of the file to either COPY (do
> >not delta the
> >file, put a full version in every time) or to MERGE (put only
> >delta of file
> >changes into the repository)...
> >
> >On Friday 18 February 2005 01:28 am, Jesper Vad Kristensen wrote:
> >> Larry Jones wrote:
> >> >It's better to do:
> >> >
> >> >  *.[Gg][Ii][Ff] -k 'b' -m 'COPY'
> >>
> >> (Amazing what you can do in CVS!)
> >>
> >> But why the -m 'COPY'?
>
> That's very interesting. We're working with binary source code here and
> have some performance issues when retrieving stuff from branches (due to
> the backtracking or whatever it's called).
>
> Would you - or anyone else here - happen to know if storing the whole
> copy of the file each time speeds up retrieval in branches?
>
> Regards,
>
> Jesper Vad Kristensen
>
>
> ___
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://lists.gnu.org/mailman/listinfo/info-cvs

-- 
David A. Bartmess
Software Configuration Manager / Sr. Software Developer
eDingo Enterprises
http://edingo.net
_
jSyncManager Development Team (http://www.jsyncmanager.org)
jSyncManager Email List
(https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel)
 
 But one should not forget that money can buy a bed but not sleep, 
 finery but not beauty, a house but not a home, 
 medicine but not health, luxuries but not culture, 
 sex but not love, and amusements but not happiness.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs and ssh

[Jean-Rene David]

Please don't top post.

* Serbulent UNSAL <[EMAIL PROTECTED]>:
> No i am a newbie for cvs and trying to install it first. But after
> installation i can't connect.

Well from your original message, it looks like it's installed fine. But
then you're trying to check something out of an empty repository. You
need to put something in it first. Use the 'cvs import' command with
appropriate arguments.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet?
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: cvs and ssh

[Jean-Rene David]

* Serbulent UNSAL <[EMAIL PROTECTED]>:
> # cvs -d /var/cvsroot init 
> # chown -R cvs.cvs /var/cvsroot 
>
> #export CVS_RSH=ssh 
>
> Here is the error message 
>
> usta:/home/usta# cvs -d :ext:[EMAIL PROTECTED]:/var/cvsroot checkout
> module 
> Password: 

Did you import anything in your repository before doing a checkout?
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: jar files in cvs repository

[David A. Bartmess]

Used in the cvswrappers file, the -m gives the mode of the file to the cvs 
admin command, setting the mode of the file to either COPY (do not delta the 
file, put a full version in every time) or to MERGE (put only delta of file 
changes into the repository)... 

On Friday 18 February 2005 01:28 am, Jesper Vad Kristensen wrote:
> Larry Jones wrote:
> >It's better to do:
> >
> > *.[Gg][Ii][Ff] -k 'b' -m 'COPY'
>
> (Amazing what you can do in CVS!)
>
> But why the -m 'COPY'? My man cvs says:
>
>-m message
>Use message as log information, instead of
>invoking an editor.
>
> Regards,
>
> Jesper Vad Kristensen
> Aarhus, Denmark.
>
>
> ___
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://lists.gnu.org/mailman/listinfo/info-cvs

-- 
David A. Bartmess
Software Configuration Manager / Sr. Software Developer
eDingo Enterprises
http://edingo.net
_
jSyncManager Development Team (http://www.jsyncmanager.org)
jSyncManager Email List
(https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel)
 
 But one should not forget that money can buy a bed but not sleep, 
 finery but not beauty, a house but not a home, 
 medicine but not health, luxuries but not culture, 
 sex but not love, and amusements but not happiness.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Info-cvs Digest, Vol 27, Issue 40

[David A. Bartmess]

When you added the files, did you specify "-kb" for the add command for the 
binary jar files? If not, you'll have to change the status of the files using 
the cvs admin command as follows:

cvs admin -kb myJarFile.jar
cvs update -A myJarFile.jar

cvs commit

This will reset the status of the jar file(s) to a binary format, meaning no 
translation will be done on the file. Then you copy the "good" version back 
over the sandbox (corrupted) version, and commit it.

If you imported (created a NEW module under CVS by importing the entire 
directory structure), it "should have" noted the binary status automatically 
because of the magic numbers, but sometimes it can make mistakes. 

For future reference and possible use now, you can checkout and modify the 
CVSROOT/cvswrappers file from the repository, and add the filename pattern in 
the syntax:

pattern option 'value' [option 'value' ...]
for example, add the following line to make all *.jar files binary when added.
*.jar -m 'COPY' -k 'b'

This tells CVS when a jar file is added, use the "COPY" merge strategy (it 
keeps a complete copy of the file, instead of just the delta version), and to 
mark it as binary mode in the CVS status for the file.

if you modify the cvswrappers file BEFORE you import, you should be able to 
avoid this hassle...

Hope this helps!

On Wednesday 16 February 2005 10:01 pm, Rajeev R wrote:
> Hi all,
> I am using eclipse cvs repository view for downloading the cvs
> repository jar files.
> Could any one pls tell me how the jar files can be downloaded after
> importing them to the cvs repository.
>
> Thanks & Regards,
>
> Rajeev.R
>
>
>
> On Wed, 16 Feb 2005 08:56:45 -0800 (PST), [EMAIL PROTECTED]
>
> <[EMAIL PROTECTED]> wrote:
> > Send Info-cvs mailing list submissions to
> >info-cvs@gnu.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >http://lists.gnu.org/mailman/listinfo/info-cvs
> > or, via email, send a message with subject or body 'help' to
> >[EMAIL PROTECTED]
> >
> > You can reach the person managing the list at
> >[EMAIL PROTECTED]
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Info-cvs digest..."
> >
> > Today's Topics:
> >
> >   1. jar files in cvs repository (Rajeev R)
> >   2. RE: jar files in cvs repository (Jesper Vad Kristensen)
> >   3. Re: Undo check out (David A. Bartmess)
> >
> > --
> >
> > Message: 1
> > Date: Wed, 16 Feb 2005 17:47:30 +0530
> > From: Rajeev R <[EMAIL PROTECTED]>
> > Subject: jar files in cvs repository
> > To: info-cvs@gnu.org
> > Message-ID: <[EMAIL PROTECTED]>
> > Content-Type: text/plain; charset=US-ASCII
> >
> > Hi ,
> >
> > We have a cvs repository that contains jar files.
> > When I imported the jar files, I could not get the jar files as such.
> >
> > All the jar files had no content ,when I checked them out from the cvs
> > repository and of 1 KB size .
> >
> > Pictures and .java files are coming perfectly ,but jar files are not
> > downloading perfectly.
> >
> > Could any one please help me in this case,
> > where i want to download jar files from the cvs repository perfectly,
> > when checked out.
> >
> > Thanks & Regards,
> >
> > Rajeev,
> > Software Engineer
> >
> > --
> >
> > Message: 2
> > Date: Wed, 16 Feb 2005 14:30:42 +0100
> > From: "Jesper Vad Kristensen" <[EMAIL PROTECTED]>
> > Subject: RE: jar files in cvs repository
> > To: 
> > Message-ID:
> ><[EMAIL PROTECTED]>
> > Content-Type: text/plain;   charset="us-ascii"
> >
> > Raajev,
> >
> > >We have a cvs repository that contains jar files.
> > >When I imported the jar files, I could not get the jar files as such.
> > >
> > >All the jar files had no content ,when I checked them out from the cvs
> > >repository and of 1 KB size .
> > >
> > >Pictures and .java files are coming perfectly ,but jar files are not
> > >downloading perfectly.
> >
> > It's a bit unclear what you're doing, and what you did up to the point
> > where you wish to checkout the files again, but are you sure you didn't
> > by accident corrupt the JAR files (they're BINARY, right, so you gotta
> > -kb them)?
> >
> > Regards,
>

Re: Undo check out

[David A. Bartmess]

As Paul said, you don't have to "undo" the checkout. If you checked out a 
wrong module, remove that directory, and try again. The repository won't have 
anything locked unless (again, as Paul said) you used the cvs admin command 
to lock the files... 

On Wednesday 16 February 2005 12:35 am, Paul Sander wrote:
> You don't.  CVS doesn't have the notion of a traditional checkout that
> involves locking.  There may be a record in history that a workspace
> has been created (which is what CVS calls a "checkout") that can be
> countered by invoking the "cvs release" command.
>
> If, on the other hand, someone is trying to simulate a reserved
> checkout mechanism using the "cvs admin" command, there's a different
> option to that command that clears the RCS level lock.  But using "cvs
> admin" in this manner is strongly discouraged.
>
> On Feb 15, 2005, at 10:16 PM, [EMAIL PROTECTED] wrote:
> > I have wrongly checked out a compononet.  How will I undo this
> > checkout.  Removing lock manually is one option but is there any other
> > better way to do this.
>
> --
> Paul Sander   | "When a true genius appears in the world, you may
> [EMAIL PROTECTED] | know him by this sign:  that all the dunces are in
>
>| confederacy against him."  -- Jonathan Swift,
>
> writer.
>
>
>
> ___
> Info-cvs mailing list
> Info-cvs@gnu.org
> http://lists.gnu.org/mailman/listinfo/info-cvs

-- 
David A. Bartmess
Software Configuration Manager / Sr. Software Developer
eDingo Enterprises
http://edingo.net
_
jSyncManager Development Team (http://www.jsyncmanager.org)
jSyncManager Email List
(https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel)
 
 But one should not forget that money can buy a bed but not sleep, 
 finery but not beauty, a house but not a home, 
 medicine but not health, luxuries but not culture, 
 sex but not love, and amusements but not happiness.


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Restricting use of 'cvs rtag' & 'cvs tag' commands

[David Leskovac]

Hello,

We are currently using an ancient version of CVS (1.11.1p1) on a rather old 
Linux server (Red Hat 6). I intend to upgrade to CVS 1.11.19 & eventually 
upgrade the Linux OS. In the course of our CVS upgrade discussion we started 
discussing how to increase security with regards to CVS access. I am aware of 
the cvsacls script that provides fairly fine-grained permissions to do 
check-ins but is there also a way of restricting who is allowed to do certain 
cvs commands? In particular, we would like to restrict who can create/delete 
tags & branch tags. Is it possible to restrict 'cvs tag' & 'cvs rtag' on a user 
or group level?

Thanks,
-Dave


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Can I allow user to only have permission in branches but not HEAD?

[David Jiao]

Hi, I have a question about how access permissions on branches and
HEAD. I want to restrict certain CVS users to only be able to commit
their changes to branches but not the HEAD. Yet at the same time, I
want to allow them to check out modules from the HEAD. Is this doable?

Thanks!

David Jiao


___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Please help troubleshooting connection problem via SSH

[J. David Boyd]

Chris Weiss <[EMAIL PROTECTED]> writes:

> J. David Boyd wrote:
> 
> >Chris Weiss <[EMAIL PROTECTED]> writes:
> >
> >  
> >>I've got one client who is having trouble connecting to our CVS
> >>server. I'm trying to troubleshoot the problem, but am not having much
> >>luck.
> >>
> >>Our setup is CVS server 1.11.5, client 1.11.1.3, we're connecting via
> >>SSH tunnel. We've got the keys syncronized, so the client doesn't need
> >>to enter a password to connect.
> >>I'm able to successfully connect using the client's account, but he is
> >>not. We've been successfully using this system for a while with a
> >>dozen users who are having no issues connecting.
> >>He can SSH in, so we know it's not a blocked port issue.
> >>The client's machine is WinXP (unknown if SP2 is installed)
> >>
> >>Client-wise, we're using WinCVS and Turtle - I've tried CVS from the
> >>command prompt as well with no success.
> >>
> >>The symptoms are - if trying to do a Checkout or get a module list,
> >>the client freezes with no output at all. We've left it for minutes at
> >>a time with no response.
> >>Here is the client's output for CVS Version:
> >>Client: Concurrent Versions System (CVSNT) 1.11.1.3  (Build 57k)
> >>(client/server)
> >> Server:
> >>
> >>
> >>
> >>Does anyone have any ideas what could be causing his issues or any
> >>further steps to take to troubleshoot this? I'm new to the whole CVS
> >>thing (my experience was all Perforce) and this is all a trial-by-fire
> >>for me.
> >>
> >
> >You say that you can use the client's account no problem, but you don't mean
> > his machine, just his login info,of course.  It sounds as if his
> > CVSROOT string is incorrect.  What did you all put into
> >the preferences section of WinCVS to connect him to your system?
> >
> >That wouldn't stop him from manually SSHing into the system, but it would
> >certainly keep WinCVS from connecting.
> >
> >Dave
> >
> >  
> I'm pretty sure it's not a CVSROOT issue unless there's something
> machine specific in that variable. We'd set it multiple times over the
> course of testing (it's not persistent in the shell) and several of
> those times were copy/pastes from CVSROOT settings that worked
> successfully on my machine (we've been debugging via IM).
> 
> I'm also guessing that if there was a bad CVSROOT, at least one of the
> clients would have given a descriptive error and not just hung.
> 
> Thanks for the ideas though!
> 

So you are saying that the client can connect to CVS through SSH on the
command line?  Just not in WinCVS or Turtle?  That definitely would not be a
CVSROOT problem then.

Sorry for being no help...





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

Re: Please help troubleshooting connection problem via SSH

[J. David Boyd]

Chris Weiss <[EMAIL PROTECTED]> writes:

> I've got one client who is having trouble connecting to our CVS
> server. I'm trying to troubleshoot the problem, but am not having much
> luck.
> 
> Our setup is CVS server 1.11.5, client 1.11.1.3, we're connecting via
> SSH tunnel. We've got the keys syncronized, so the client doesn't need
> to enter a password to connect.
> I'm able to successfully connect using the client's account, but he is
> not. We've been successfully using this system for a while with a
> dozen users who are having no issues connecting.
> He can SSH in, so we know it's not a blocked port issue.
> The client's machine is WinXP (unknown if SP2 is installed)
> 
> Client-wise, we're using WinCVS and Turtle - I've tried CVS from the
> command prompt as well with no success.
> 
> The symptoms are - if trying to do a Checkout or get a module list,
> the client freezes with no output at all. We've left it for minutes at
> a time with no response.
> Here is the client's output for CVS Version:
> Client: Concurrent Versions System (CVSNT) 1.11.1.3  (Build 57k)
> (client/server)
>  Server:
> 
> 
> 
> Does anyone have any ideas what could be causing his issues or any
> further steps to take to troubleshoot this? I'm new to the whole CVS
> thing (my experience was all Perforce) and this is all a trial-by-fire
> for me.

You say that you can use the client's account no problem, but you don't mean
his machine, just his login info,of course.  

It sounds as if his CVSROOT string is incorrect.  What did you all put into
the preferences section of WinCVS to connect him to your system?

That wouldn't stop him from manually SSHing into the system, but it would
certainly keep WinCVS from connecting.

Dave



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

Re: [cvsnt] Re: Problem with OpenSSH version 3.9p1

[David Robison]

I rolled back to an older version of cygwin1.dll and all works fine now!
David
Tony Hoyle wrote:
David Robison wrote:
I recently did an update from cygwin and updated to OpenSSH version 
3.9p1. Now, every time I try to work with a CVS repository that uses 
SSH authentication, the csv process hangs with no output. CVS works 
fine for repositories with pserver authentication. Any ideas what 
might be going on? Any way I can further debug this? I'm using CVSNT 
version 2.0.41a that came with WinCVS.

It sounds like that openssh is broke, if the older one worked.
Have you tried asking on the cygwin list if anyone else if having the 
problem?

Tony
___
cvsnt mailing list
[EMAIL PROTECTED]
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt

--
David R Robison
Open Roads Consulting, Inc.
708 S. Battlefield Blvd., Chesapeake, VA 23322
phone: (757) 546-3401
e-mail: [EMAIL PROTECTED]
web: http://openroadsconsulting.com

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

Cannot access ^M/CVSROOT

[David Robison]

I am having trouble access a CVS repository that I have been able to 
access in the past. I'm using CVS from the cygwin distribution on 
Windows XP SP2. I'm using cvs version 1.11.17. When I try a command, I 
get the error:

Cannot access /src/master^M/CVSROOT
No such file or directory
What is interesting is that between the "master" and the "/CVSROOT" is a 
0x0d character. This seems to be causing trouble, Any idea where this is 
coming from? Any idea what to try?

Any help would be appreciated.
David Robison
--
David R Robison
Open Roads Consulting, Inc.
708 S. Battlefield Blvd., Chesapeake, VA 23322
phone: (757) 546-3401
e-mail: [EMAIL PROTECTED]
web: http://openroadsconsulting.com

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

RE: Do most people checkout read-only and use "cvs edit"?

[Karr, David]

I'm not talking about locking.  It's always impractical to "check out
with locks", in any SCM.  I'm just talking about what happens in the
user's client view.  I was under the impression before that "cvs edit"
just affects the file in the user's client view.  Does this also lock
the file on the server?

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Tom Copeland
> Sent: Wednesday, July 07, 2004 11:12 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Do most people checkout read-only and use "cvs edit"?
> 
> 
> On Wed, 2004-07-07 at 14:01, Karr, David wrote:
> > Or, do people checkout read-write and never use "cvs
> > edit"?
> 
> Yup, that's what I do.  Optimistic locking and all that sort 
> of thing, you know...
> 
> Yours,
> 
> Tom
> 
> 
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://lists.gnu.org/mailman/listinfo/info-cvs
> 


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

Do most people checkout read-only and use "cvs edit"?

[Karr, David]

I have a question about how people use CVS.  How common is it to always
checkout and update read-only, and then use "cvs edit" when you start
working on a file?  Or, do people checkout read-write and never use "cvs
edit"?  I have always thought that modules should be checked out
read-only, and "cvs edit" is only used when you start to work on a file.
However, I'm getting the impression that that appears to be an
"alternative" strategy, and even deemphasized.

In fact, in the WinCVS interface, the "cvs edit" functionality is under
the "Trace" submenu, hiding it from the first-level menu.

Other SCMs use the strategy that I'm used to as the primary strategy
("checkout" read-only, and do a specific operation to put the file into
edit mode).


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

How to make "checkout" and "update" leave files read-only?

[Karr, David]

I'd like to ensure that only files that I've done "cvs edit" on are
writable.  I've used CVS in the past, and I thought I was able to set it
up this way.  I added "cvs -r" to my $HOME/.cvsrc file (along with other
settings that are working), but "update" is leaving files writable that
I haven't "edit"ed.


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

Why does "cvs status" send the entire file to the server (apparently)?

[Karr, David]

The connection to my cvs server is somewhat slow from where I am right
now, so I can clearly see when things are taking a long time.  I tried
running "cvs -t status -v" so I could see more details of what's
happening.  It appears that for each file it encounters, it is sending
the entire contents of the file to the cvs server (it says "Sending file
'...' to server").  Why does it need to do this?  This is especially
frustrating for large binary files, which take a long time to tell me
that they are "Unknown" to the server.


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

"inflate: unknown compression method" after server upgrade to 1.11.16

[David Carson]

When I use a client which inserts the global '-l' option together with
my newly upgraded server, I get the expected "global `-l' option
ignored" warning.

However, if I also specify a compression level, I get the following:

  [EMAIL PROTECTED] tools] cvs -nq -z1 up
  cvs update: inflate: unknown compression method
  cvs [update aborted]: reading from server: Input/output error

Server:
cvs 1.11.16
RedHat 7.2

Client:
cvs 1.11.1p1
RedHat 7.2

Note that I have many clients deployed, so I'd like to understand the
problem (not just deploy newer clients).

Thanks,
David

Please respond to this newsgroup, not my e-mail address.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs

RE: File date and timestamp

[Flagg, David]

Thanks for the info.

The reason the timestamp is important is because the file is part of an
external delivery.  the customer has previous deliveries and flags files
whose timestamps have changed.  As a result, they wonder why the
timestamp changed on this binary file, yet we didn't inform them of any
changes with that particular capability.

-Original Message-
From: Jim.Hyslop [mailto:[EMAIL PROTECTED]
Sent: Monday, June 28, 2004 11:45 AM
To: Flagg, David; [EMAIL PROTECTED]
Subject: RE: File date and timestamp


Flagg, David wrote:
> This is a re-post.  This seems like it could possibly be a 
> common problem someone might have.  Is there a more 
> appropriate forum somewhere else?  Thanks.
Hmmm.. I thought I saw a response to your original message from someone
else
already, but I don't see it in my 'trash' or in the archive.

> >  -Original Message-
> I have a binary file that is in my repository, libtemp.a, 
> which has the following timestamp in cvsroot (i.e., timestamp 
> in the Unix filesystem): Jun 18 09:42.  Apparently, this is 
> the time when I last tagged the file.
That would make sense; applying a tag modifies the RCS file.

> When I check out the file (with WinCVS, by the way), the 
> date on the file is (as viewed by Win 2K): 5/3/2004 6:47 PM.  
> This is the date/time when I last committed the file.  This 
> also agrees with the timestamp in the Entries file.
> > 
> When I committed the file, the timestamp on the file was 
> 12/24/2003 2:23 PM.  It is important that this be the 
> timestamp that is associated with the binary file, as it is 
> pulled in from another source.  When I check this file out, I 
> want the timestamp to continue to be 12/24/2003 2:23 PM.
Timestamps are an interesting issue. The problem is, how do you decide
which
timestamp to use on the checked-out file?

Even if you succeed, there is the issue of updating to a specific tag.
If
you issue the command 'cvs update -r1.1' the timestamp of the file will
become the current date and time. While this may seem strange and
unintuitive at first, you must consider that CVS also interacts with
other
systems - such as build systems. If CVS used the original modification
timestamp or the check-in timestamp, the dependency system would not
flag
the dependencies as out-of-date.

> (1) Is there a way that I should have committed this file 
> such that I can get the behavior I want?
I believe that the rcs command allows options to specify the timestamp
to
apply to the file. Or, you can hack the CVS source to get the behaviour
you
want.

This introduces another issue, though - 'cvs log' and anything else that
uses the date option works on the date in the RCS file. You could
introduce
subtle, unexpected behaviour changes with this modification.

> (2) How can I correct the situation for this particular file?
You could manually edit the RCS file.

It sounds to me, though, like you need a configuration management system
that is aware of things beyond the current scope. Why is it so important
to
maintain the exact timestamp of the binary file?

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)


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

File date and timestamp

[Flagg, David]

This is a re-post.  This seems like it could possibly be a common problem someone 
might have.  Is there a more appropriate forum somewhere else?  Thanks.

>  -Original Message-
> From: Flagg, David  
> Sent: Friday, June 25, 2004 10:26 AM
> To:   '[EMAIL PROTECTED]'
> Subject:  File data and timestamp
> 
> I have a binary file that is in my repository, libtemp.a, which has the following 
> timestamp in cvsroot (i.e., timestamp in the Unix filesystem): Jun 18 09:42.  
> Apparently, this is the time when I last tagged the file.
> 
> When I check out the file (with WinCVS, by the way), the date on the file is (as 
> viewed by Win 2K): 5/3/2004 6:47 PM.  This is the date/time when I last committed 
> the file.  This also agrees with the timestamp in the Entries file.
> 
> When I committed the file, the timestamp on the file was 12/24/2003 2:23 PM.  It is 
> important that this be the timestamp that is associated with the binary file, as it 
> is pulled in from another source.  When I check this file out, I want the timestamp 
> to continue to be 12/24/2003 2:23 PM.
> 
> (1) Is there a way that I should have committed this file such that I can get the 
> behavior I want?
> 
> (2) How can I correct the situation for this particular file?
> 
> Thanks!
> 


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

File data and timestamp

[Flagg, David]

I have a binary file that is in my repository, libtemp.a, which has the following 
timestamp in cvsroot (i.e., timestamp in the Unix filesystem): Jun 18 09:42.  
Apparently, this is the time when I last tagged the file.

When I check out the file (with WinCVS, by the way), the date on the file is (as 
viewed by Win 2K): 5/3/2004 6:47 PM.  This is the date/time when I last committed the 
file.  This also agrees with the timestamp in the Entries file.

When I committed the file, the timestamp on the file was 12/24/2003 2:23 PM.  It is 
important that this be the timestamp that is associated with the binary file, as it is 
pulled in from another source.  When I check this file out, I want the timestamp to 
continue to be 12/24/2003 2:23 PM.

(1) Is there a way that I should have committed this file such that I can get the 
behavior I want?

(2) How can I correct the situation for this particular file?

Thanks!



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

Re: how to checkin binary files

[David A. Desrosiers]

> May someone tell me how to checkin a binary file into my repository?
> Thanks a lot..

man 1 cvs

Look for the -k options. 


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

Re: Major revision numbers

[david]

> [EMAIL PROTECTED] wrote:
> > revision numbers are for CVS's internal use, you should not care what
> > they are.  Use tags if you want meaningful information.
> Weee... for the most part I agree.
> 
> However, there are times when you need to compare two revisions that are not
> tagged. If we followed the philosophy that you never use or see the numeric
> revision, then you'd have to apply two tags for the sole purpose of seeing
> what changed between the two revisions. It's much easier to say
> 
> cvs di -r1.123 -r1.124
> 
Right.  In that case, you're using 1.123 and 1.124 as arbitrary
designators ("magic cookies"), and you still shouldn't care what
they are, as long as you can type them fairly easily.  I don't
think Larry is saying that you shouldn't refer to them, but
that it shouldn't matter exactly what they are.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

Re: Binary release announcements?

[david]

> [ On Wednesday, February 18, 2004 at 10:21:41 (-0500), Jim.Hyslop wrote: ]
> > Subject: RE: Binary release announcements?
> >
> If you can't, or won't, build the software you use yourself then you
> need to find someone who can _and_ who you trust to do that for you.
>
Some people seem to be awfully trusting.
 
> Perhaps that's some big software company like Microsoft.
> 
> Perhaps it's just some group of volunteers who stake their reptuations
> on the quality of the software they create (even though most every one
> will disclaim all responsibility for damages or loss you might incur
> when using their software  :-).
>
Why put that parenthetical observation only after your second alternative?
I haven't seen any software company act as if it took responsibility
for such damages or loss.  Software license agreements and EULAs haven't
changed from the days when they were guarantees that these things were
disks, and would remain so for ninety days, coupled with a long list
of things you couldn't do with any software you happened to find on
there.
 
> The problem with computers and digital networking is that the malicious
> acts can be perpetrated several steps removed from where one might
> expect them to happen and by the time anyone's aware of what's happened
> it's far too late because these speedy little machines and wire's we've
> created have already spread the damage further and wider than any human
> could ever imagine possible without understanding the many quantum leaps
> computing technology gives the criminal.
> 
> PLEASE read Schneier's book "Secrets & Lies".
>
Greg and I have disagreed before.  This isn't one of those times.
I don't know if there are other good books that cover the same ground,
but I do recommend that one.
 
-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

Re: Pros/Cons - Concurrent Editing

[david]

> What are the pros and cons of concurrent editing?. CVS supports and 
> advocates concurrent editing, whereas configuration tools like VSS use the 
> "locked" model of editing, to which the developers are very much used to. 
> What are the benefits of concurrent editing ( using CVS ) and what 
> problems could arise? 
> 
In my experience, concurrent editing happens.  When Jane is working on the
next major feature, Edward is going to get this request for a quick bug
fix, if nothing else.  Or Bill and Nancy are working on different
features, but they both require making minor changes to three programs
in common.

What tools like VSS do in this case is force you to work around them.
Jane releases the file, Edward changes it, then Jane grabs it again
and has to incorporate Edward's fix.  (I've seen people in Jane's
position forget to incorporate those fixes, also.  It's real easy
to copy the changed file over and forget to merge in the fix.)

CVS encourages this sort of thing, and supports it.  In CVS,
Jane picks up Edward's change automatically, and the tool supports
the merging of fixes.

While there are some software practices that are best avoided, and
which you do not want your tools to encourage, concurrent editing
cannot be avoided in general, and it is best if your tools support it.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

Re: Best Practices enquiry

[david]

> 
> On the flip side, and maybe this is what Jim really meant, you can tag
> your committed versions on the contributor branch when the bug fix is
> done (and after the merge is complete).  Then remember that tag for the
> next bug fix.  You can use that tag as the common ancestor for the next
> merge.  The bad part of this is that you must religiously tag the contributor
> branch after every merge (which is counter-intuitive), and you must remember
> the tag (perhaps for a long period of time) until the next bug fix.  Note
> also that this procedure must be bootstrapped by applying the first bug fix
> tag at the time the branch is created.  All told, this is a fine method that
> also fits neatly into the "best practice" category.
> 
If you can get your developers to use a script to merge (which they'll
likely want to do when they see the manual way), and have a consistent
tag naming convention, you can automate the merging process.  I did that
once, and it worked very well.  The developers were happy, and I was
happy not to have to deal with user merge problems.



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

Re: CVS server upgrade?

[David R. Chase]

Jim,

Just wondering what minor problems you had, just in case they might pertain
to other peoples' migration strategies (or my own someday)?

Thanks!
David R. Chase
Senior Unemployed Software Developer  ; )

- Original Message -
From: "Jim.Hyslop" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, February 02, 2004 3:00 PM
Subject: RE: CVS server upgrade?


> Courier [mailto:[EMAIL PROTECTED] wrote:
> > Here is I would like to do: I will take currently cvs server off line,
> > then tar the whole Repository, then bring up a new system and
> > cp and untar
> > Repository on new server. Our cvs server is a stand alone
> > server. All my
> > users are accessing via pserver. I don't have any problems
> > with username
> > and their password migrations, but just concerned about cvs
> > Repository.
> When we upgraded our server, we took a similar approach.
>
> We scheduled a dry-run of the process ahead of time, just to make sure
there
> were no problems and to work out any unforeseen problems. The dry run
proved
> very valuable, because there _were_ some minor things we had overlooked.
> This saved us the time (and embarassment) of cutting off our users from
the
> repository multiple times.
>
> In order to minimize the impact on the users, we took the original server
> off-line just long enough to create the tarball. As soon as the tar was
> complete, we restarted the server in read-only mode (create an empty
> CVSROOT/writers file to make the whole repository read-only). Thus, people
> could still check out and browse the repository, but they couldn't check
> anything in (and thus throw the two repositories out of sync).
>
> After we were satisfied the new server was up and running properly, we
> simply did a DNS switch on the server name (the name the users see is an
> alias to the actual machine name).
>
> --
> Jim Hyslop
> Senior Software Designer
> Leitch Technology International Inc. (<http://www.leitch.com/>)
> Columnist, C/C++ Users Journal (<http://www.cuj.com/experts>)
>
>
>
> ___
> 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: what's to stop a developer from nuking the repository?

[david]

> [ On Tuesday, January 20, 2004 at 15:13:08 (-0600), [EMAIL PROTECTED] wrote: ]
> > Subject: Re: what's to stop a developer from nuking the repository?
> >
> > > If you have a trusted network and you do feel comfortable with telnet
> > > and rlogin then USE THEM -- DO NOT USE PSERVER.
> > >
> > The logic for using pserver over ssh would be that it's harder to set
> > ssh up right.
> 
> Using pserver over SSH is about the biggest fallacy for "security" I can
> imagine for anything in this context.
>
However, setting up pserver is easier than setting up ssh.  Setting up
ssh requires reading more instructions, which are not necessarily as
accessible.  I set up remote users on a VPN with pserver once because
I wasn't familiar with the ssh-agent concept and didn't know what to
do.  (I know better now.)

My point is that setting up cvs with rsh is as easy as using pserver,
and that provides more accountability.

> If you're going to use SSH, then JUST USE SSH for goodness sake!
>
ssh is the correct way to use CVS over anything other than a secure LAN
(and I share an earlier contributor's feelings about "crunchy on the
outside, soft and chewy on the inside" LANs).  On a secure LAN, rsh
is about as easy to set up as pserver and works well.

So, it looks to me like we're in fairly argumentative agreement here.
 
-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

Re: what's to stop a developer from nuking the repository?

[david]

> [ On Tuesday, January 20, 2004 at 11:03:38 (-0500), Larry Jones wrote: ]
> > Subject: Re: what's to stop a developer from nuking the repository?
> >
> > I think that's still overstating the case.  If you run CVS on a network
> > where you can trust people enough that you're confortable running
> > telnet or rlogin, then pserver is fine.
> 
> Telnet and rlogin and similar still provide on heck of a lot more
> accountability (over a trusted network) than pserver could ever possibly
> do.
>
The key here is accountability, I think.  pserver has effectively no
accountability, and telnet/rlogin have some (as far as I know).
 
> If you have a trusted network and you do feel comfortable with telnet
> and rlogin then USE THEM -- DO NOT USE PSERVER.
>
The logic for using pserver over ssh would be that it's harder to set
ssh up right.  Not a really compelling reason, but it's all I can think
of.  However, setting rsh up is as trivial as setting pserver up, so
I'd have to agree here.
 
-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

Re: what's to stop a developer from nuking the repository?

[david]

> 
> Please forgive me if I am mistaken, and in any case I certainly don't want 
>to start a flame war, but am I right in thinking that Greg's opinion does 
>not reflect the majority view? 
> 
I can't speak for the majority, but I pretty much agree with Greg.

Quibble time:  *if* you run cvs on a network you're sure is secure
and everybody on it can be absolutely trusted (to the point where you'd
be perfectly comfortable giving the root password to anybody who had an
actual need for it), pserver is usable.  It serves to prevent mistakes.
It may be slightly easier to set up than rsh, or it may not be.

However, if there is any shadow of doubt, then all pserver gives you
is anonymous access, since anybody who wants to do anything not directly
traceable to themselves can easily use somebody else's identity.

Given a valuable code base, and employees, I'd figure that the danger
of having a disgruntled employee is there, and I'd want to use something
more traceable than pserver.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

suscribe

[Prince David]

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

verifymsg working with netbeans & eclipse?

[David Muller]

Title: verifymsg working with netbeans & eclipse?






Hi,

We have the standard verifymsg change from the documentation to check for "BugId: " but netbeans and eclipse users are getting an error "cannot exec //bugid.verify - file not found".  Path is correct and file permissions are correct in fact via the command line and tortoisecvs it works fine.

Anyone have experience with this problem?


Thanks,

-Dave



____

David E. Muller

Configuration Manager

Overture Services, Inc.  

www.overture.com

Office: 760.476.6406 

Mobile: 760.458.2714 



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

cvs-1.11.10 win32 VC98 cannot find "assert" during build

[David Everly]

The following command builds cvs-1.11.9, but not cvs-1.11.10 under
windows:

   nmake /f cvsnt.mak CFG="cvsnt - Win32 Debug"

The failure appears to be:

link.exe @c:\temp\nma01012.
filesubr.obj : error LNK2001: unresolved external symbol _assert
.\WinDebug/cvs.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'link.exe' : return code '0x460'
Stop.

There is related information about "assert" earlier in the build
log:

cl.exe /nologo /MLd /W3 /Gm /GX /Zi /Ob1 /I "windows-NT" /I
"lib" /I "src" /I "zlib" /D "_DEBUG" /D "WIN32" /D "_CONSOLE" /D
"HAVE_CONFIG_H" /Fp".\WinDebug/cvsnt.pch" /YX /Fo".\WinDebug/"
/Fd".\WinDebug/" /c ".\windows-NT\filesubr.c"
filesubr.c
.\windows-NT\filesubr.c(766) : warning C4013: 'assert' undefined;
assuming extern returning int

My compiler is Microsoft Visual Studio / VC98.

I don't know much about building on windows, not sure what else
to provide, so here is the seemingly related source code change:

windows-NT$ cvs diff -rcvs_1_11_9 -rcvs_1_11_10 filesubr.c 
Index: filesubr.c
===
RCS file: /users/home/tibco/tibadmin/cvs/cvs/windows-NT/filesubr.c,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.2
diff -r1.1.1.1 -r1.1.1.2
743a744,782
> /* char *
>  * xresolvepath ( const char *path )
>  *
>  * Like xreadlink(), but resolve all links in a path.
>  *
>  * INPUTS
>  *  path  The original path.
>  *
>  * RETURNS
>  *  The path with any symbolic links expanded.
>  *
>  * ERRORS
>  *  This function exits with a fatal error if it fails to read the link for
>  *  any reason.
>  */
> char *
> xresolvepath ( path )
> const char *path;
> {
> char *hardpath;
> char *owd;
> 
> assert ( isdir ( path ) );
> 
> /* FIXME - If HAVE_READLINK is defined, we should probably walk the path
>  * bit by bit calling xreadlink().
>  */
> 
> owd = xgetwd();
> if ( CVS_CHDIR ( path ) < 0)
>   error ( 1, errno, "cannot chdir to %s", path );
> if ( ( hardpath = xgetwd() ) == NULL )
>   error (1, errno, "cannot readlink %s", hardpath);
> if ( CVS_CHDIR ( owd ) < 0)
>   error ( 1, errno, "cannot chdir to %s", owd );
> free (owd);
> return hardpath;
> }
> 




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

Re: False status indication with WinCvs 1.2

[David Wood]

I've seen this before; it's related to daylight savings time issues with 
Windows. WinCVS 1.3 has the fix, 1.2 doesn't. As far as I could tell it 
was an annoyance that killed performance and ruined the effectiveness of 
the in-pane modified reporting, but I couldn't think of a case where it 
was actually dangerous.

Nonetheless this means (for me) that 1.2 is DOA. You might want to be more 
specific about your reasons for needing it, others may be able to suggest 
alternatives...

[EMAIL PROTECTED] wrote on 12/12/2003 
12:58:24 PM:

> 
> Hello,
> 
> 
> Is there anybody using WinCvs 1.2 and having troubles with the
> modified / unmodified indication for files? 
> 
> A company that's a client of mine is having such a problem with WinCvs
> 1.2 on a Windows 2000 + SP3 machine. They have 30+ installations of
> WinCvs 1.3 and there they have no problem with that, but the one
> person that needs WinCvs 1.2 (due to a lock function that they use
> with Germany) is having a false indicative of modified files. 
> 
> We clear the working directory, do a new checkout and the problem
> comes back after a while. 
> 
> Any hints on what else should I look?
> 
> 
> TIA,
> -- 
> Godoy. <[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

Re: SSHD user-switching under Cygwin/XP (was Re: Case insensitivity ad nauseum)

[David Wood]

Now I'm really out on a limb, but, what user is sshd running as before it 
switches? Does logging into sshd without a password, using a key instead, 
merely mean that no switch from this "default sshd user" occurs? If that's 
the case, can we adjust the "default user" that sshd runs as?

[EMAIL PROTECTED] wrote on 12/10/2003 
02:09:17 PM:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Nathan Kidd wrote:
> 
> > Derek Robert Price wrote:
> >
> >>> I didn't carefully read over this whole list of permutations, but at
> >>> first glance, perhaps it's just the domain for oberon that's 
missing?
> >>>
> >>> e.g.
> >>>
> >>> net use z: \\empress\oberon /user:empress\oberon  
> >>>
> >>>
> >>>
> >>> Yep.  That's it, I just also have to login using a password rather 
than
> >>> my private/public key pair.
> >>
> >>
> >> As I revisit this, I note however, that this is not sufficient.  I'm
> >> trying to set up automated testing, so I couldn't enter the password 
if
> >> I wanted to - even saving to a file and attempting to echo it to ssh
> >> doesn't work because ssh grabs the TTY to get the password.  I really
> >> need to use public key authentication, but this prevents SSHD from
> >> grabbing the Windows authentication tokens.
> >>
> >> I think maybe this is a Windows (combined with SSHD?) limitation that 
I
> >> cannot get any access to network resources without authenticating 
with a
> >> password?
> >
> >
> > I don't know if this helps in your situation, but if you are always
> > testing from the same machine you could have a persistent connection
> > to some share on empress using oberon's password.  Any subsequent
> > access to any share on empress will automatically use this
> > user/password without prompting for it.  That is, it is sufficient to
> > simply run:
> >net use * \\empress\oberon
> >
> > But then if you do this you might as well make the original connection
> > you want as persistent and never even bother with "net use" in your
> > script.
> >
> > (On W2K, at least, it doesn't even seem possible to use a password
> > from STDIN.)
> 
> 
> That doesn't work.  As near as I can tell now based on my experiments
> and reading, my problem is that I am attempting to launch the tests via
> an automated ssh connection from another computer.  SSHD on Cygwin does
> user-switching, but only gets Windows auth tokens if you use your
> Windows password to login.  Since I can't use a password with ssh from
> an automated script, I cannot get Windows auth tokens, and without
> Windows auth tokens, Windows won't let me see or mount, _any_ network
> share, not even a share that allows anonymous connections.
> 
> Derek
> 
> - --
> *8^)
> 
> Email: [EMAIL PROTECTED]
> 
> Get CVS support at !
> - --
> I will not carve gods.
> I will not carve gods.
> I will not carve gods...
> 
>   - Bart Simpson on chalkboard, _The Simpsons_
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
> 
> iD8DBQE/129cLD1OTBfyMaQRAufGAKDGEogiW2K/vheO9F7KeKnA3N/V8wCg3GMq
> 16ABCrtdg9dYiLjNChQb2lw=
> =LBvf
> -END PGP SIGNATURE-
> 
> 
> 
> 
> ___
> 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: CVS Version CHange

[david]

Greg Woods:
> 
> In CVS the release number of RCS-Id is like any useless and almost
> atrophied organ -- however it's impossible to give it up without
> also giving up backwards compatability of the internal repository
> structure.
>
It also is necessary as a "magic cookie" - an otherwise meaningless
but ordered reference to each revision of a file.  When referring to
releases, one should always use symbolic tags, but when testing it
is often necessary to know which particular revision one is using.

I've often found it useful to correlate the results of "cvs annotate"
and "cvs diff" with the results of "cvs log".  Sometimes there will
be code in a program that isn't working just right, and I don't know
what it was supposed to be doing, so tracking it down to the revision
that introduced it and getting the PR number out of the checkin
comment is very useful.

So, we can't get rid of the ability to see the revision numbers, although
I wouldn't complain if we got rid of the ability to specify them.
 
> Perhaps CVS should just hide the "1." from view, though doing that in
> the RCS keyword expansion would be fraught with problems too and it may
> still be needed in many command-line parameters.  Perhaps translating it
> into a symbolic value such as "TRUNK." wherever visible would be better.
>
Could be.  The RCS revision number looks too much like a standard sort
of release designation, and that leads to trouble.  It appears to
contain more information than is needed to specify a revision.  I
like the idea of giving the revisions simple numbers (as Subversion
does) to show their arbitrariness.
 
> > I agree that tags should be the _preferred_ way to do this, but I really do
> > not see why you are so vehemently opposed to manually forcing revision
> > numbers under special circumstances. What problems will this introduce?
>
While I'm not as vehement as Greg, I don't see any reason to manually
force revision numbers.  I see no point in it.  At best you can have
a crude, awkward, and easy-to-get-wrong substitute to what you can
do easily and reliably with tags.
 
> > Again, under special circumstances, not under day-to-day use.
> 
> The problem is that once it's been done then it becomes an every-day
> issue from then to the end of the life of the repository (unless it's
> undone, of course).
>
It can be very hard to undo.  I don't think that having such revision
numbers is that much of a problem, but if they are to mean anything
whatsoever it is an everyday issue, and it's simply not worth it.
 
> > The major drawback with tags is that they can be moved or deleted, without
> > any history of the changes.
> 
> If these sorts of things worry you then perhaps CVS is not the right
> tool for your needs.  :-)
>
Sometimes there is no "right" tool, but we've argued about that before.
 
> CVS is not very much of a policy enforcement tool, if any of one at all.
> (despite the abilities of features such as "taginfo" scripting hooks)
>
On the other hand, it is nice to have ways to avoid making irretrievable
mistakes (and removing or moving a tag can be that).  I've made many
of those in my lifetime despite knowing better.  As the CVS admin, I
managed to remove a branch tag from a directory once, and then modified
one of my principles ("Never hit the return/enter key before you
carefully examined what you've just typed") for doing such by adding
the clause "and it doesn't count as careful examination if anybody is
talking to you at the time".

Fortunately, later versions of CVS have made the particular error I
made impossible, but "taginfo" is still a reasonable thing to consider.
 
-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

Re: Limitation on --allow-root pserver options?

[David Wood]

You could consider using xinetd alongside Solaris inetd (just for the CVS 
port). It would be a simple experiment to set it up and see if it, too, 
exhibits the problem. 

[EMAIL PROTECTED] wrote on 12/02/2003 
03:38:25 AM:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Mark <[EMAIL PROTECTED]> writes:
> 
> > We have cvs pserver 1.11.1p1 setup on solaris 2.8 and a wrapper script
> > in /etc/inetd.conf to allow many --allow-roots (we have many
> > apps/groups/business units we provide CM support for, thus the need to
> > many repos). We use WinCVS 1.3 for the client.
> 
> Okay. However, there are many bug fixes to cvs available in the latest
> cvs 1.11.9 version of cvs.
> 
> > Currently we have 58 --allow-root options setup in the wrapper script.
> > The 58th --allow-root does not work/is not recognized.
> > 
> > When we try to login via pserver:
> > - the client gets "no such repository" message
> > - the server logs a "login refused for" in /var/adm/messages 
> > 
> > When I moved that 58th -allow-root to the top of the -allow-root list,
> > it worked, but then the new last one in the list, now has the above
> > described issues.
> 
> Well, clearly some problem is being uncovered. If you are able to
> upgrade to a newer version of cvs and still have the problem, then
> it may be possible to help you debug the problem on this list.
> 
> > Is this a solaris limitation or a cvs limitation (there are about 2513
> > characters that make up the --allow-root argument string, excluding 
any
> > spaces)?
> 
> I am not aware of such a limitation, however, you could test it 
yourself.
> Take a simple program like this:
> 
> % cat testit.c
> #include 
> int main(int argc, char *argv[]) {
> int i; for ( i = 0; i < argc; i++ ) printf("%d: %s\n", i, argv[i]);
> return(0);
> }
> %
> 
> Compile it and give it all of the arguments you setup in your wrapper
> script for cvs and see what happens.
> 
> > I could use different ports on the server to balance out the
> > repositories but WinCVS 1.3 doesn't retain port info inside the
> > CVS admin subdirectory files in the workares which causes problems
> > for users who have to work out of repos on different ports at the same
> > time. (ie. instead of WinCVS 1.3 gathering all it needs from a
> > workarea's CVS subdir to commit/update etc... it uses the current port
> > settings in the WinCVS preferences regardless of what the workarea is
> > currently being used this is quite annoying and confusing)... if
> > this issues has been fixed in WinCVS 1.3, please let me know.
> > 
> > Any help/insight/suggestions is appreciated. yes we only have one
> > solaris server to use, and yes we must have independent
> > repositories..
> > 
> > Thanks,
> > 
> > Mark
> 
>Good luck,
>-- Mark
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.3 (FreeBSD)
> 
> iD8DBQE/zE+B3x41pRYZE/gRAsJMAJsGOsCUaYAUE++6sIWazSnGfHTV9ACdFVck
> Lyqb6jf6h+thjyzNIlIJkUY=
> =3nB/
> -END PGP SIGNATURE-
> 
> 
> ___
> 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: Please help..

[David Wood]

I had the same thought, Steve, and I think the same concern - given what 
he did, the repository _might_ have been a valid one the first time 
through - and it might be a valid repository of the repository now. But 
without knowing the nuts and bolts of the repository and import process, I 
can think of reasons why it wouldn't be. 

Of course, there's not much to lose in performing the experiment, as long 
as you take care and keep copies of everything. I'll be curious to hear if 
following these instructions would work.

[EMAIL PROTECTED] wrote on 11/26/2003 
02:46:10 PM:

> David,
> 
> Perhaps John could try this?
> A suggestion to untangle:
> 
> 1. Create a repository properly.
> 2. Copy the .v.v files into the repository manually.
> 3. Checkout the files into a working directory. (getting a .v file)
> 4. Copy the .v files manually into the repository.
> 5. Checkout the files into a working directory. (hopefully getting back 
> the originals.)
> 
> This assumes that the creating the repository over the original files 
> didn't muck them up too much.
> 
> John,
> Don't just try the above suggestion till we get more input.  I'm just 
> floating an idea and I think the experts here might have something more 
> to say about it.
> 
> Understanding how the repository is different from the working directory 

> is crucial.  A few clif notes:
> * You create a repository in an empty directory.  This repository is 
> separate and very different from the data you actually work on.  In our 
> case our repository is in /swdev/cvsroot.  This is what the CVSROOT 
> environment variable is set to.
> * You use ONLY cvs commands to get data into and out of the repository. 
>   Ideally you'd never directly touch the repository data.
> * You work in a separate working directory (off of your home directory 
> probably, in my case /home/derosier/projects) and you check out your 
> source code modules there.  When you've made some changes you want to 
> check in, you do a 'cvs commit' command.
> * Even if you run CVS locally, think of it as a server.  It's a black 
> box where you store things.  You make requests to get data out, work on 
> it, and then make a request to store data back in. From an OOP point of 
> view: It is encapsulated data with a very well defined interface or API. 

>   Use the interface, don't touch the data.
> * If the above doesn't make sense to you, then read it again, read the 
> CVS manual again until it makes sense.  Do not try to setup and use CVS 
> without understanding this.
> 
> Hope this helps,
> - Steve
> 
> 
> David Wood wrote:
> > You need to spend some time with the manual, and/or the various 
tutorials 
> > on the subject. As you are discovering, if you're not understanding 
the 
> > manual, forging ahead anyway may not be the best decision.
> > 
> > A repository is a database (that holds its data in RCS files - ending 
in 
> > .v). You create a repository in an _empty_ directory, somewhere 
separate 
> > (with cvs init), and then you import sources into it from wherever you 

> > have them (with cvs import). 
> > 
> > Then you do a cvs checkout to create a new CVS working directory from 
the 
> > repository - and that is where you then do your work. (Often people 
will 
> > move or zip the original directory they imported from, and then move 
their 
> > CVS working directory into its place.)
> > 
> > You've created a repository right on top of where you are working, 
which 
> > is bad. I confess at this point I'm not sure what you've got in those 
> > files (perhaps someone wiser than myself can offer a shortcut?), but 
my 
> > best guess is that it will be easier to recover from backups than to 
> > reconstruct your sources from what's left of them now (.v.v files).
> > 
> > At any rate, since you have backups, there is no reason to panic. In 
the 
> > future, just put your repository somewhere separate 
(/home/cvs/repository 
> > ?). And of course, have another go at the manual (or some of the other 

> > reading materials) to get a better handle on how the system works.
> > 
> > John Wards <[EMAIL PROTECTED]> wrote on 11/26/2003 12:25:42 PM:
> > 
> > 
> >>On Wednesday 26 November 2003 4:57 pm, David Wood wrote:
> >>
> >>>First, did you work for 18 months on something without making 
backups?
> >>
> >>Yes yes of course, but they are not with me currently and I am in a 
bit 
> > 
> > of a 
> > 
> >>panic!
> >>
> >>
> >>>Second, to get help you will need to be much more specific ab

Re: Case insensitivity ad nauseum

[David Wood]

Is the problem that you're not sure how to get the network drive into the 
sshd filesystem root? Or that when you try to that it fails?

If it were the latter, it would be reminiscent of a similar problem I had 
trying to get apache to serve files from a network drive on Windows XP. We 
found that the Local System Account that the apache service ran under by 
default did not have permissions to access the drive. 

If you were having trouble with it, you might look into what user the sshd 
process is running as, and whether that user has permission to access the 
drive.

[EMAIL PROTECTED] wrote on 11/26/2003 
02:25:14 PM:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I settled on a compromise for the nonce.  I fixed the latest case
> insensitivity bug I knew of in 1.11.x and removed case insensitivity
> support from feature entirely.  I've also added some tests of behavior
> involving heterogeneous combinations of case sensitive and case
> insensitive clients and servers to both branches though I've yet to get
> it set up for nightly testing (if anyone knows how to get Cygwin sshd to
> allow access to a mounted Samba share via its login shell, I could use
> some assistance).
> 
> Since things look stable without case insensitivity support, I will
> probably remove support from stable too if any new bugs crop up.
> 
> I'll probably roll a new release early next week.
> 
> Derek
> 
> - --
> *8^)
> 
> Email: [EMAIL PROTECTED]
> 
> Get CVS support at !
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
> 
> iD8DBQE/xP4ZLD1OTBfyMaQRAjN4AJ0dlk5zjIsae5xN6elNbLw9TKpl9ACg2KGD
> DIdO/rpFI8YlFAqUrOukha4=
> =q+r2
> -END PGP SIGNATURE-
> 
> 
> 
> 
> ___
> 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: Please help..

[David Wood]

You need to spend some time with the manual, and/or the various tutorials 
on the subject. As you are discovering, if you're not understanding the 
manual, forging ahead anyway may not be the best decision.

A repository is a database (that holds its data in RCS files - ending in 
.v). You create a repository in an _empty_ directory, somewhere separate 
(with cvs init), and then you import sources into it from wherever you 
have them (with cvs import). 

Then you do a cvs checkout to create a new CVS working directory from the 
repository - and that is where you then do your work. (Often people will 
move or zip the original directory they imported from, and then move their 
CVS working directory into its place.)

You've created a repository right on top of where you are working, which 
is bad. I confess at this point I'm not sure what you've got in those 
files (perhaps someone wiser than myself can offer a shortcut?), but my 
best guess is that it will be easier to recover from backups than to 
reconstruct your sources from what's left of them now (.v.v files).

At any rate, since you have backups, there is no reason to panic. In the 
future, just put your repository somewhere separate (/home/cvs/repository 
?). And of course, have another go at the manual (or some of the other 
reading materials) to get a better handle on how the system works.

John Wards <[EMAIL PROTECTED]> wrote on 11/26/2003 12:25:42 PM:

> On Wednesday 26 November 2003 4:57 pm, David Wood wrote:
> > First, did you work for 18 months on something without making backups?
> 
> Yes yes of course, but they are not with me currently and I am in a bit 
of a 
> panic!
> 
> > Second, to get help you will need to be much more specific about 
exactly
> > what you did when you "figured out how to make a repository from your
> > original source files." How did you set everything up (CVSROOT, etc)? 
What
> > commands did you run? It sounds like you have some confusion about
> > repositories versus working directories and the import process. Did 
you
> > read the CVS manual before you started? I fear from your description
> > you've gone pretty far down the wrong way.
> 
> Yes I read the manual and I should have probably been a bit more 
detailed but 
> I thought ah someone wil know an easy undo comand.seems not then :-(
> 
> I got a bit confused with all the CVSROOT stuff etc.
> 
> My source files are in /home/johnwards/www/sportnetwork
> 
> I thought I should have done this:
> 
> CVSROOT=/home/johnwards/www
> export CVSROOT
> cvs init
> 
> Then:
> cvs import -m "SportNetwork first import" -d sportnetwork sportnetwork 
start
> 
> This was wrong :-( I think. As its changed all my files...
> 
> I am really confused by the manual...all I want to do is set up CVS 
using 
> my source files...how on earth do you do it as I am really 
confused..
> 
> John
> 
> 
> 



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

Re: Please help..

[David Wood]

Two things. 

First, did you work for 18 months on something without making backups? 

If you never made backups, then whether it was a mistake setting up CVS, 
some other kind of mistake, hardware failure, fire, or theft, you were 
destined to lose your work. I hope, however you resolve this issue, that 
you will always make nightly backups in the future. If you are ahead of 
me, and you have backups after all, then you can always use them to undo 
whatever you've done. I'm guessing, but at this point it may be easiest.

Second, to get help you will need to be much more specific about exactly 
what you did when you "figured out how to make a repository from your 
original source files." How did you set everything up (CVSROOT, etc)? What 
commands did you run? It sounds like you have some confusion about 
repositories versus working directories and the import process. Did you 
read the CVS manual before you started? I fear from your description 
you've gone pretty far down the wrong way. 

[EMAIL PROTECTED] wrote on 11/26/2003 
11:32:10 AM:

> Hi All,
> 
> I am seriously new to CVS.
> 
> I have a large project that has been developed by my self for the past 
18 
> months but is about to be taken on by a few other people so I though CVS 

> would be a good way of working.
> 
> I seem to have turned all of my original source files within the 
directory to 
> have a .v extention and a lot of stuff has been added to these files.
> 
> Please tell me their is an easy way to get my files back!
> 
> I seem to have figurered out now how to make a repository from my 
original 
> source files but they all have a double .v (.v.v) file extention now!!! 
Doh.
> 
> Thanks in advance!!
> Cheers
> John
> 
> 
> 
> ___
> 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: CVS admin

[david]

> How do I set-up my self as a cvs admin on the server
> side?
>
What do you mean by "cvs admin"?  As a CVS administrator, you should
have full permissions on the repository or repositories.  To use
"cvs admin" commands, either have no Unix group "cvsadmin", or be
a member yourself.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

pretty printer on commit

[David Everly]

I would like to run all commits of .h and .cc files through a pretty
printer to automatically assist in later merges and conformance to
style.  I'm running a pserver.  Are there any tips I should know of
how to do this before trying?

Thanks,
Dave.


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

Re: CVS merge

[David Wood]

I think the problem is the start and end points of your merge.

If I have a trunk, and I created a branch from that trunk, tagging it at 
the point it was created, I would use the following to merge the branch 
back into the trunk:

-j branch_CREATED -j branch

Often this can simply be abbreviated as

-j branch

If you are doing something more complicated than this, please tell us the 
structure of the branches involved.

There are additional details on this subtle and complex feature here, in 
the manual under the "Branching and Merging" section:

http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_5.html#SEC54

I advise you to read it carefully, or you will get into trouble.

[EMAIL PROTECTED] wrote on 11/11/2003 
09:23:19 PM:

> Hi,
> 
> I don't think my following merge result is correct. I
> did a merge in branch1 to join branch2 as following
> command: 
> 
> branch1$ cvs -q update -Pd -kk -j branch1 -j branch2
> 
> There is only one file shown me the conflicts by
> "<<" and ">>" comments embedded in the file.
> Many other files in branch1 are simply replaced by
> branch2 source files and created .#file1.h.1.2.3,
> .#file2.c.1.2.5 
> 
> For example, the file1.h in branch1 includes three
> functions A(), B() and C(). The file1.h in branch2 has
> only two functions A() and B(). I expected that the
> merged new file would include A(), B() and C(), but to
> be surprised, the new merged file has only A() and
> B(), same as branch2 source file. The function C() was
> simply lost. Is this normal behavior or am I missing
> something here?
> 
> (CVS version 1.10 for Window, I guess, it is
> irrelevant)
> 
> Thank you.
> 
> yh
> 
> 
> 
> __
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> 
> 
> ___
> 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: Can't create a module in cvswin1.13

[David Wood]

Do you have a log of what happened during the import, and during your 
attempt to check out?

How are you setting your CVSROOT, in an environment variable, or on the 
command line?

Are you using the command line cvs, or wincvs (etc)?

[EMAIL PROTECTED] wrote on 11/11/2003 
02:52:07 PM:

> Dear All:
> 
> I wasn't able to create a module in my local
> repository.  I followed the instruction verbatim!  I
> am running from a local drive and once I imported an
> emty or populated directory, I can't check it out
> locally??  It keeps telling me the "Module" name can't
> be found?
> 
> I ran the Admin command "Get the cvs modules"  But cvs
> tells me theat" No module entries found! Consult your
> repository's admin." 
> 
> What could have done wrong!!
> 
> Thanks,
> 
> __
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
> 
> 
> ___
> 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: Rephrasing: question about merging branches

[David Wood]

Derek Robert Price <[EMAIL PROTECTED]> wrote on 11/06/2003 04:37:03 PM:
> I see it now, and I thought that the conflicts you now say don't occur
> were the ones you objected to in the first place.

Not at all. The conflicts that troubled me were happening because I was 
double-merging (when bringing B back to the trunk, merging from 1-4 
instead of 2-4), _until_ I used the technique laid out in that email.

The conflicts in question are what you describe, here: 

"If A branched first, then 2->4 will attempt to remerge changes made to 
the trunk between the base of A and the base of B, causing the same sort 
of spurious conflicts you were attempting to avoid." 

And that did not seem to be true. 

It seemed to me that those changes are not merged twice - as I said, "The 
changes between the start of A and the start of B are not in A, and they 
are inherent in B." So I am wondering if I tested it wrong and am thinking 
about it wrong? 

> Regardless, some of what you said in that email was correct and some
> wasn't, but I don't think you can solve the general case without saving
> a merge history for each revision of each file.

If individual files can't merge, and only whole branches can, I confess I 
don't understand why that is true, unless by saying the "general case" we 
are actually discussing something different than I imagine.

One other thing I was wondering about was what I found when experimenting 
with the approach you suggest (using multiple merges): that conflicts 
arise during the interim steps, making the process unworkable. 

I am interested in single-step merges both because it _seems_ possible 
generally to construct one appropriate to a given case, and because they 
appear to me to avoid the issues of conflicts during interim merge steps.

> It isn't.  The existing GCA algorithm is merely a convenience to avoid
> typing a start-revision in the most common case (merging from a branch
> to its parent) and I think it actually confuses more people than it

Let me clarify what I mean a bit more. I want to generalize the process of 
finding a merge start point based on merge and branch information. I think 
the CVS "GCA" system is an interesting approach when working with branch 
information alone. 

If I understand it correctly, it is analogous to walking backwards up the 
ancestry of the source branch, searching for the most recent branch point 
on any common parent, of the souce or the destination branch (whichever is 
older).

What I am experimenting with is the notion that if you add merge 
information to the mix, this approach still works. I am gathering that you 
don't think it will; but I guess what I am wondering, in that case, is, 
"how will it fail?"


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

Re: Rephrasing: question about merging branches

[David Wood]

Derek Robert Price <[EMAIL PROTECTED]> wrote on 11/06/2003 08:57:22 AM:

> The way to avoid only processing this for whole branch merges is to
> track individual commits as change sets.  For example, store that the
> sum of changesets for file1 1.2 -> 1.2.4.7 have been merged into the
> trunk.  Then later, if a merge is attempted from 1.1 through
> 1.2.4.103.2.17, CVS could notice that the changesets above lay in the
> path and merge 1.1 -> 1.2 & 1.2.4.7 -> 1.2.4.103.2.17 as two separate
> merges.
> 
> If 1.2.4.103.2.1 -> 1.2.4.103.2.10 has already been merged as well, then
> that could be subtracted as well, leaving CVS with three merges:
> 
> ~1.1 ->1.2
> ~1.2.4.7 -> 1.2.4.103
> ~1.2.4.103.2.10 -> 1.2.4.103.2.17
> 
> and so on.

I'm curious, do you think that multi-step merges will be required for the 
general case?

Did you see my response to your original email? You had thought that 
multiple merges were necessary for that example, but when I studied it it 
didn't look that way.

http://mail.gnu.org/archive/html/info-cvs/2003-11/msg00053.html

Isn't it possible that, if I do whole branch merges, I can handle 
everything with single merge operations... subject to caveats:

> No, I don't think there is a general way to handle this.  Or, at least
> the general way is to allow the user to pass a switch or somesuch to
> override the "smart" behavior so the merge can be reapplied.  Note that
> this requires that CVS report when it skips portions of a requested
> merge so that the user will know this is necessary.

Certainly that switch is assumed. But say for the sake of argument that it 
is "all or nothing." In other words, if you want to use the smart merges, 
you have to follow the smart merge rules.

That merely means doing some things a bit differently; for instance, if 
you want to use merge as a tool in more unconventional ways (I want to 
re-merge this branch because changes from it were accidentally deleted), 
you have to find other solutions. In the case of this example, I'd 
envision using the conventional merge operations to easily simulate 
undoing the "mistake" without additional complexity.

> |My cursory examination of CVS's GCA algorithm leaves me with the
> |impression that it relies on properties of the revision numbering 
system,
> |which if true makes it abundantly clear why there is no simple path to
> |making CVS smarter about GCA, even if it did have the information about
> |merge activity that it needed.
> 
> 
> No, this would not make CVS smarter about GCA.  This would make CVS
> smarter about merging.  Please do not misuse the term "GCA" this way.
> "GCA" has a well-defined meaning and well-established usage in CVS and
> the algorithm we are discussing has little to do with determining the
> ancestor, except possibly for determining an implicit start point for a
> merge request, which is exactly how the GCA is used currently.

I will be careful not to confuse the term "GCA" with any new, more 
automated system for determining merge start points. I meant to draw the 
comparison only because what I envisioned for such a new system seemed 
functionally very similar to the existing CVS GCA algorithm (in function, 
of course, not in implementation). 

Or am I wrong even in this?


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

Re: Rephrasing: question about merging branches

[David Wood]

Derek Robert Price <[EMAIL PROTECTED]> wrote on 11/05/2003 12:43:14 PM:
> "Greatest Common Ancestor", or GCA, is a term that refers to the RCS
> revision structure and always means the more recent revision two
> revisions have in common, often a branch point, but in the case of a
> branch of a branch and the trunk, note that the GCA is on the trunk, not
> the base revision of the branch, but the base revision of its parent.

So in other words, you are saying: in the case where the branch (child) of 
a branch (parent) merges back to the trunk (grandparent), the GCA is on 
the grandparent, at the point where the parent begins. Right?

> CVS determines GCA when you only specify one revision in a merge as a
> convenience for the common case, merging from a branch into its parent.
> This does not mean that the first revision of a merge specification
> should always be called a "GCA".
> 
> Yes, it would be convenient if CVS were smart enough to track what data
> has already been merged to various locations and attempt to
> intellegently exclude these data sets in following merges.  This has
> been suggested many times in the past.
>
> In practice, CVS does not currently keep track of the necessary data and
> even if it did, the problem is a very hard one.  There _are_ reasons a
> user could wish to specify a merge twice.  They accidentally copied old
> files over the new ones which had contained the merge; another developer
> removed the merge changes by hand and committed in conjunction with code
> you do not want removed.  etc.Basically, CVS would have a hard time
> tracking what you manually did to its merge result.
> 
> If someone were to solve this problem and submit a patch that
> implemented the solution including documentation and tests cases which
> addressed these sorts of issues and any others that arose, believe me, I
> would be one of the first to vote that CVS incorporate the code.

I am hopeful that someone will be me.

My initial approach has been to use a "wrapper" which executes branches 
and merges, generating and applying tags in addition to branching and 
merging, and maintaining extra state data in a database. I believe that 
the tool has all of the necessary information available; the question now 
is using it to determine the correct "merge start point" in a general way.

I only intend to support whole branch merges, and I have been under the 
impression that I can focus solely on eliminating over- and under-merging. 
I believe cases such as your examples, where it is desirable to double 
merge, or to deliberately eliminate part of the merge, cannot be handled 
in a general way - although perhaps you will disagree?

My cursory examination of CVS's GCA algorithm leaves me with the 
impression that it relies on properties of the revision numbering system, 
which if true makes it abundantly clear why there is no simple path to 
making CVS smarter about GCA, even if it did have the information about 
merge activity that it needed.




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

Re: Rephrasing: question about merging branches

[David Wood]

Derek Robert Price <[EMAIL PROTECTED]> wrote on 11/05/2003 10:38:02 AM:
> No.  The GCA has not changed and CVS determines it correctly.  You
> simply no longer wish to merge from the GCA forward because some of
> those changes were already merged to your destination (from another
> branch and at your own request - CVS did nothing wrong) and you wish to
> avoid conflicts.

I am not saying CVS is doing anything wrong; I think it is following its 
design precisely. I think my problem may be with terminology. 

If I merge from a child to the trunk, and then I later merge it again, 
what is the greatest common ancestor on that second merge? Still the 
beginning of the child? Or is it now point of the first merge?

It sounds like you are saying the former - following the strict CVS 
definition for GCA, that is right. But what about an alternate definition 
of "ancestry" based on both branches _and_ merges?

Right now to do that second merge I have to tell CVS where to start - it 
no longer uses its GCA algorithm to figure that out for me. But I am 
telling it the new common "ancestor" myself - the point of the previous 
merge (as opposed to the point of the branch). Isn't this an analogous 
process to CVS' current GCA? 


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

Re: Rephrasing: question about merging branches

[David Wood]

Please correct me if I'm wrong. I _think_ this is the "greatest common 
ancestor" problem. And finding one is actually something CVS does for you 
- on the first mege (with a single -j). Which is usually OK in cases where 
a branch immediately "dies" (i.e. becomes dormant) afterwards.

The problem is that CVS does not "remember" that a merge took place. After 
a merge, the "map" of ancestry that was built by branch operations is no 
longer correct. And from that point on, CVS relies on _you_ to find the 
GCA. 

[EMAIL PROTECTED] wrote on 11/05/2003 
03:55:38 AM:

> Is it just me, or is this getting way too complex to be usable except by 

> CVS experts?
> 
> I thought I was comfortable with the issues surrounding branches and 
> merges, even though we are not using branches yet here.  But I don't 
> understand half of what you folks are saying.
> 
> Worse: in my understanding this isn't even a particularly complex 
> case.  Let me see if I have this right.  You want to merge changes made 
on 
> a branch back into the main development stream, then merge that with the 

> changes on another branch.  Surely **everyone** will need to do this, 
> sooner or later?
> 
> Andy Jones.
> 
> 
> 
> 
> At 03:37 am 5/11/03, David Wood wrote:
> >I am not sure about something.
> >
> > > |>If branch A and branch B in your example don't branch form the 
same
> > > |>point on the trunk, a merge from point 2 to point 4 into the trunk
> >might
> > > |>still not do what you want.  If branch B branched first, then 2->4 
may
> > > |>back out changes made to the trunk between the base of B and the 
base
> >of
> > > |>A.  If A branched first, then 2->4 will attempt to remerge changes
> >made
> > > |>to the trunk between the base of A and the base of B, causing the 
same
> > > |>sort of spurious conflicts you were attempting to avoid.
> >
> >Assume B is branched first. A merges to the trunk. Then A merges to B.
> >Then B merges to the trunk as well.
> >
> >I think the trick here is what happens when A merges to B. If you do 
that
> >merge like this:
> >
> >(in B's working dir):
> >cvs update -j branchA_CREATED -j 3
> >
> >(3 == where A merges to B) then you are correct. This merge will be
> >missing changes from between the start of B and A - ALREADY! In other
> >words, with respect to B, part of A was left out, since it was created
> >before "branchA_CREATED" - on the trunk. But I think this is really the
> >"wrong way" to merge A into B.
> >
> >The "right" way is to do it would be to say:
> >
> >cvs update -j branchB_CREATED -j 3
> >
> >Then branch B does indeed end up incorporating "everything" from branch 
A.
> >In other words, the changes on the trunk after B was created until A
> >starts, and then all then all the changes in A. So when doing that kind 
of
> >merge, always use the newest common ancestor (in this case, the start 
of
> >B).
> >
> >Now let's look at your other scenario. When A is created before B,
> >everything else being equal, I did not receive spurious conflicts doing
> >that last merge in a single step (2-4, Jamie's way) after all! You say
> >there should be, because that I am "remerging changes made to the trunk
> >between the base of A and the base of B." But I can't see where the
> >redundancy should come from.
> >
> >The changes between the start of A and the start of B are not in A, and
> >they are inherent in B.
> >
> >So goes my theory. Perhaps we are making different assumptions?
> >
> > > |>The only clean way to do this in the general case is to tag branch 
B
> > > |>before and after your merge from A at point 3 and merge B back 
into
> >the
> > > |>trunk as two merges:
> > > |>
> > > |>~cvs up -j 1 -j pre-3
> > > |>~cvs up -j post-3 -j 4
> >...
> > > Oops, yes, you are correct.  What I said was correct if point 2 & 3 
were
> > > the same (at point 2 all of branch A was merge to both the trunk and
> > > branch B).  A clean merge to the trunk without conflicts from a 
repeated
> > > merge with distinct points 2 & 3 would require the two commands I 
listed
> > > above and a third merge:
> > >
> > > ~cvs up -j 2 -j 3
> >
> >So if I understand you all correctly, a generalized merge formula would
> >be:
> >
> >cvs update -j start-of-branchB -j pre-3'

Re: Rephrasing: question about merging branches

[David Wood]

I am not sure about something.

> |>If branch A and branch B in your example don't branch form the same
> |>point on the trunk, a merge from point 2 to point 4 into the trunk 
might
> |>still not do what you want.  If branch B branched first, then 2->4 may
> |>back out changes made to the trunk between the base of B and the base 
of
> |>A.  If A branched first, then 2->4 will attempt to remerge changes 
made
> |>to the trunk between the base of A and the base of B, causing the same
> |>sort of spurious conflicts you were attempting to avoid.

Assume B is branched first. A merges to the trunk. Then A merges to B. 
Then B merges to the trunk as well. 

I think the trick here is what happens when A merges to B. If you do that 
merge like this:

(in B's working dir):
cvs update -j branchA_CREATED -j 3

(3 == where A merges to B) then you are correct. This merge will be 
missing changes from between the start of B and A - ALREADY! In other 
words, with respect to B, part of A was left out, since it was created 
before "branchA_CREATED" - on the trunk. But I think this is really the 
"wrong way" to merge A into B.

The "right" way is to do it would be to say:

cvs update -j branchB_CREATED -j 3

Then branch B does indeed end up incorporating "everything" from branch A. 
In other words, the changes on the trunk after B was created until A 
starts, and then all then all the changes in A. So when doing that kind of 
merge, always use the newest common ancestor (in this case, the start of 
B).

Now let's look at your other scenario. When A is created before B, 
everything else being equal, I did not receive spurious conflicts doing 
that last merge in a single step (2-4, Jamie's way) after all! You say 
there should be, because that I am "remerging changes made to the trunk 
between the base of A and the base of B." But I can't see where the 
redundancy should come from. 

The changes between the start of A and the start of B are not in A, and 
they are inherent in B.

So goes my theory. Perhaps we are making different assumptions?

> |>The only clean way to do this in the general case is to tag branch B
> |>before and after your merge from A at point 3 and merge B back into 
the
> |>trunk as two merges:
> |>
> |>~cvs up -j 1 -j pre-3
> |>~cvs up -j post-3 -j 4
...
> Oops, yes, you are correct.  What I said was correct if point 2 & 3 were
> the same (at point 2 all of branch A was merge to both the trunk and
> branch B).  A clean merge to the trunk without conflicts from a repeated
> merge with distinct points 2 & 3 would require the two commands I listed
> above and a third merge:
> 
> ~cvs up -j 2 -j 3

So if I understand you all correctly, a generalized merge formula would 
be:

cvs update -j start-of-branchB -j pre-3'
cvs update -j 2 -j 3
cvs update -j post-3' -j 4

in that order?

What if branchB had made changes that would conflict with branchA's 
changes, and the merge from A to B is to correct that conflict and bring B 
into sync _before_ it merges with the trunk?

Following this pattern, I will still get that conflict between B and the 
trunk on the first command - even though those conflicts had already been 
resolved "post-3'". Nothing subsequent would work without manually 
duplicating the conflict resolution already present in B...


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

Re: Rephrasing: question about merging branches

[David Wood]

I would say your ascii graphic is admirable!

What you are saying matches what I'm seeing in tests, and I think I get it 
now.

I believe my problem has been a silly confusion with the way update -j -j 
works. 

I understand a merge between 1 and 4 (and for that matter, a reverse-merge 
between 4 and 1) well enough.

Essentially, I mistakenly envisioned a merge between 3' and 4 - rather 
than 2 and 4. Hence my fear about loss or mistreatment of changes before 
the child-to-child merge. 

I think what all this means is that branchB is now essentially merging 
against branchA (having received common chagnes by, and resolved conflicts 
with) branchA... and the merge delta with the trunk must now use branchA 
(at point 2) as a reference point in order to correctly reflect changes 
against the trunk.

It is potentially confusing, but you have made it seem very simple. Thank 
you!

-David

Jamie Wellnitz <[EMAIL PROTECTED]> wrote on 11/04/2003 11:50:35 
AM:

> Sorry for the ascii graphic in advance . . .
> 
> If you have (* indicates merge point):
> 
> branchA and branchB originated from trunk at point 1.
> branchA merged to trunk at point 2 on branchA and 2' on trunk.
> branchA then merged to branchB at point 3 on branchA and 3' on branchB.
> Now, we want to merge branchB (point 4) to the trunk (4').
> 
>   branchA  23
> /-\-\>
>  1 /   \ \   4'
> trunk --* \ -*>
>\2' \/
> \---*--/-->
>   branchB   3' 4
> 
> I think you want the common ancestor of the current branchB tip and
> trunk tip.  That would be point2 on branchA.  (This is assuming you
> did a full merges, not just a few changes, from A->trunk and A->B.)
> So assuming you put tags down to keep track of the merge points, you
> might try (on the trunk):
> 
> cvs update -j point2 -j point4
> 
> It looks like my point2 is your "first child merge point" and "second
> child" is the tip of branchB (where you put a tag before the merge).
> 
> Which changes before the "first child merge point" are you wondering
> about?
> 
> Thanks,
> Jamie Wellnitz
> [EMAIL PROTECTED]
> 
> On Tue, Nov 04, 2003 at 11:06:44AM -0500, David Wood wrote:
> > Let me try to put it another way.
> > 
> > I have a parent branch, and it has two child branches. If I want one 
child 
> > to merge to the parent, and then to the other child, how does that 
other 
> > child later merge to the parent as well?
> > 
> > Is it (on the parent): update -j first_child_merge_point -j second 
child
> > 
> > If so, what happens to changes from before the 
first_child_merge_point?
> > 
> > -David
> > 
> > 
> > ___
> > 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

Rephrasing: question about merging branches

[David Wood]

Let me try to put it another way.

I have a parent branch, and it has two child branches. If I want one child 
to merge to the parent, and then to the other child, how does that other 
child later merge to the parent as well?

Is it (on the parent): update -j first_child_merge_point -j second child

If so, what happens to changes from before the first_child_merge_point?

-David


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

Merge point confusion.

[David Wood]

This is a complicated problem - a brainteaser if you will. 

I have a "Home" branch, and two children which branch from home (A, and 
B). 

If I make a change in A, and then merge A into Home, great.

If I make a conflicting change in B and then try to merge B into Home, it 
gives a conflict. Also fine.

So I merge A into B, and then commit to B 

Then when I try to merge B into Home, I _still_ get conflicts - because 
A's delta is being merged twice? I think?

OK so far?

So if I have merged A into Home, and A into B, how do I then merge B into 
Home as well?

I _think_ my solution is to make a tag at the point A merged to B, and 
merge FROM that tag, TO "current B." This does appear to work. 

What confuses me about it even more is that, after I do this, I see 
changes on Home that I made to B before the point where A was merged in!

I fear I am misunderstanding the way CVS is deciding what to do with merge 
from and to points, and I cannot find answers to questions this specific 
in the references. 

Does anyone who is frighteningly familiar with merging understand what's 
going on here?

-David


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

checkin comments between tags

[David Muller]

Title: checkin comments between tags






How do I get a list of all the checking comments between 2 labels (or since the last label).

-Dave




David E. Muller

Configuration Manager

Overture Services, Inc.  

www.overture.com

Office: 760.476.6406 

Mobile: 760.458.2714 



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

Re: Conflict committed

[David Wood]

Thank you for the advice about commitinfo. I believe we will do exactly 
that as a safeguard against future problems.

I totally respect that CVS should be content agnostic, although I did have 
to rename my "cvs" java package to "cvsutil" because you can't have dirs 
named "cvs" in the repository... 

It's too bad such a safeguard can't be offered as a kind of 
optional-but-default condition. Common case, etc.

[EMAIL PROTECTED] wrote on 10/29/2003 12:07:28 PM:

> The timestamp of the file being changed will let the file with conflicts
> be committed with just a warning.
> 
> Some folks consider it useful to check for conflict markers in their
> commitinfo scripts and refuse the commit.
> 
> It is not up to cvs to determine what data patterns should or should not
> be allowed to be committed into a file.
> 
>-- Mark
> 
> Example:
> 
> % cd /tmp
> % mkdir testit
> % cd testit
> % cvs -d /tmp/testit/cvs-testrepos init
> % cvs -d /tmp/testit/cvs-testrepos co CVSROOT
> % cd CVSROOT/
> % (echo aaa; echo bbb; echo ccc) > file1
> % cvs add file1
> % cvs ci -mnew file1
> % echo ddd >> file1
> % cvs ci -madd file1
> % echo eee >> file1
> % cvs up -j1.2 -j1.1 file1
> % cat file1
> aaa
> bbb
> ccc
> <<< file1
> ddd
> eee
> ===
> >>> 1.1
> % touch file1
> % cvs ci -mconflict file1
> cvs commit: warning: file `file1' seems to still contain conflict 
indicators
> Checking in file1;
> /tmp/cvs-testrepos/CVSROOT/file1,v  <--  file1
> new revision: 1.3; previous revision: 1.2
> done
> cvs commit: Rebuilding administrative file database
> % 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.3 (FreeBSD)
> 
> iD8DBQE/n/PQ3x41pRYZE/gRAqT1AKDVi92UQJZorCK47WNQcrSBtFPWOACg3T1T
> b6nolaHXENd1+/R0jqRIxZY=
> =k4nC
> -END PGP SIGNATURE-



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

Re: Conflict committed

[David Wood]

Thank you! This is very helpful in reconstructing what happened.

[EMAIL PROTECTED] (Larry Jones) wrote on 10/29/2003 11:40:51 AM:

> David Wood writes:
> > 
> > Are my assumptions about this mistaken? What circumstances allow 
> > unresolved conflicts to be committed back to the repository?
> 
> If CVS had detected a conflict (which is recorded in the CVS/Entries
> file) and the file has not been modified, CVS will not allow the commit.
> If the file has been modified but still contains what look like conflict
> markers, CVS will issue a warning but allow the commit.  Otherwise, you
> couldn't ever commit a file containing real data that just happens to
> look like conflict markers.
> 
> -Larry Jones
> 
> You're going to be pretty lonely in the nursing home. -- Calvin



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

Conflict committed

[David Wood]

I just found that one of the developers here has managed to commit a file 
with a conflict in it.

I had been under the impression, based on documentation and past 
experience, that it was impossible to commit a file with conflict markers 
inside it. However, I just witnessed this.

Are my assumptions about this mistaken? What circumstances allow 
unresolved conflicts to be committed back to the repository?

-David


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

Re: Commit Error and Checkout Error

[david]

> Hi,
>  
> I am able to login into Cvs as root as well as a user.
> when I  have logged in as a  root i face some difficulties when trying to 
commit a file after making changes to the file.It says root is not allowed 
to commit files.
>
Right; "root" is not allowed to commit files.  This is a design feature,
intended to increase the accountability of changes.  Since "root" is
often a shared account (it's a functional account rather than a personal
one), allowing it to check in would make it impossible to determine
who checked a change in.  (It isn't quite this simple; if CVS is able
to determine who "root" really is, CVS may allow the checkin.)
  
> when i am logging as a user i am unable to checkout the files. It says 
permission denied .
>
That would mean that your user account does not have the permissions
necessary.  Your account must have read permission on all files and
directories you are going to use, execute permission on all directories,
and normally write permission on all directories.  (It is possible to
get around this, for read-only access, by setting LockDir in 
CVSROOT/config.)
  
-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

Re: Procedural ways of using CVS.

[David Wood]

The approach centers around an enhanced version of the ant CVS Task that 
is used to create branches and conduct merges. It stores information about 
branches and tags in a database, and applies it to create the appropriate 
CVS commands. 

In practice this custom Task is used twice. The first time, it gets the 
destination branch into the working directory, tags the source branch 
(according to a uniform naming convention), and does the "update [-j 
previous-merge-tag] -j current-merge-tag". The output of that operation is 
watched by what has grown into a "slightly complex" parser whose job is to 
flag conflicts.

Then you'd do your build and any other tests you want to do.

The second use involves committing the merge and tagging the destination 
branch. 

[EMAIL PROTECTED] wrote on 10/17/2003 02:51:30 PM:

> 
> David,
> 
> Read through your procedure, was quite interesting. Can you tell some 
more
> details about ANT and CVS coordination with respect to tagging, merging
> etc.
> 
> Thank you.
> 
> 
> 
> |-+--->
> | |   David Wood  |
> | |   <[EMAIL PROTECTED]>  |
> | |   Sent by:|
> | |   info-cvs-bounces+adabalap=schneider.|
> | |   [EMAIL PROTECTED] |
> | |   |
> | |   |
> | |   10/17/2003 10:50 AM |
> | |   |
> |-+--->
> 
> 
>--
> |
>   ||
>   |   To:   [EMAIL PROTECTED]|
>   |   cc:|
>   |   Fax to:|
>   |   Subject:  Re: Procedural ways of using CVS.|
> 
> 
>--
> |
> 
> 
> 
> 
> I'll share what I've developed; it may be helpful to you and helpful to 
me
> as well, if anyone has comments. Keep in mind that every situation may
> require a different approach to CVS, and ours is _not_ the most common
> usage pattern (the most common, I think, focuses on systems or 
application
> software development, and that does get some anecdotal treatment in the
> manual). In my case the job is managing ongoing development of a running
> Java web application. There are a number of parties who work on various
> aspects of it in parallel, some off-site. There are generally changes
> being developed, tested, and ready for deployment simultaneously at a
> given time.
> 
> We maintain staging and production branches. The current production 
branch
> matches exactly what is deployed at all times. The staging branch is the
> same, except that it receives new code for testing before it goes to
> production.
> 
> Projects happen on "Project branches" that fork from production when 
they
> begin, and merge to staging and then production for testing and
> deployment. A project may be continuous, or short-lived. If it lives a
> long time, other changes from the production branch since the fork may 
be
> subsequently merged into it. People may share a project, or they may use
> it alone.
> 
> We use custom Java code, primarily in several custom ant tasks, to 
manage
> merges and the associated tagging automatically, and to integrate this
> process seamlessly with other aspects of our build and delpoyment 
process.
> With one ant task, we can merge, build, and commit that merge if there 
are
> no compile errors or conflicts (which we force users to resolve in
> advance), and then actually push changes to staging and production. It's
> easy to maintain good logging this way (ant's record task), another 
bonus.
> I'm quite pleased with ant's CVS support, and with ant in general.
> 
> The assumptions in this approach work well for us because our 
application
> is fairly compartmentalized. In our case it's important not just to be
> able to separate out changes by user or project, but to be able to 
easily
> put them in (or take them out) of production without affecting other 
work
> going on in parallel. Most of all, it's important for us to not have a
> mystery about what should go in and what shouldn't when it's time to 
make
> a new production build (which may happen very frequently), although
> certainly not every 30 minutes.  :)
> 
> [EMAIL PROTECTED] wrote on 10/17/2003
> 02:22:53 AM:
> 
> >
> > >I&#x

Re: Procedural ways of using CVS.

[David Wood]

I'll share what I've developed; it may be helpful to you and helpful to me 
as well, if anyone has comments. Keep in mind that every situation may 
require a different approach to CVS, and ours is _not_ the most common 
usage pattern (the most common, I think, focuses on systems or application 
software development, and that does get some anecdotal treatment in the 
manual). In my case the job is managing ongoing development of a running 
Java web application. There are a number of parties who work on various 
aspects of it in parallel, some off-site. There are generally changes 
being developed, tested, and ready for deployment simultaneously at a 
given time. 

We maintain staging and production branches. The current production branch 
matches exactly what is deployed at all times. The staging branch is the 
same, except that it receives new code for testing before it goes to 
production.

Projects happen on "Project branches" that fork from production when they 
begin, and merge to staging and then production for testing and 
deployment. A project may be continuous, or short-lived. If it lives a 
long time, other changes from the production branch since the fork may be 
subsequently merged into it. People may share a project, or they may use 
it alone. 

We use custom Java code, primarily in several custom ant tasks, to manage 
merges and the associated tagging automatically, and to integrate this 
process seamlessly with other aspects of our build and delpoyment process. 
With one ant task, we can merge, build, and commit that merge if there are 
no compile errors or conflicts (which we force users to resolve in 
advance), and then actually push changes to staging and production. It's 
easy to maintain good logging this way (ant's record task), another bonus. 
I'm quite pleased with ant's CVS support, and with ant in general.

The assumptions in this approach work well for us because our application 
is fairly compartmentalized. In our case it's important not just to be 
able to separate out changes by user or project, but to be able to easily 
put them in (or take them out) of production without affecting other work 
going on in parallel. Most of all, it's important for us to not have a 
mystery about what should go in and what shouldn't when it's time to make 
a new production build (which may happen very frequently), although 
certainly not every 30 minutes.  :)

[EMAIL PROTECTED] wrote on 10/17/2003 
02:22:53 AM:

> 
> >I'm interested in how people organise their in-house projects from 
> an administrative point of view with CVS, for example, when they use
> branching, tagging and how (or if) they use CVS with ant, anthill 
> and how they manage frequent builds and releases (ie, every 30 minutes)
> > 
> >There is a brief amount of information in the cvs book (Open source
> dev with CVS), but I'm looking for websites or peoples own opinons 
> on how they structure their in house development with CVS.
> 
> There have already been questions (and answers) like this in the mailing 
list.
> I don't know the topic anymore but if you browse the archive you may 
find
> some good descriptions, sometimes with links to more info.
> 
> bye   Fabi



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

Re: CVS refuses to remove (branch) tag

[david]

> 
> By default, since 1.11.2, CVS refuses to delete and move branch tags
> unless you tell it you know that you are disturbing a branch tag using
> the `-B' option to tag or rtag.  This is because disturbing branch tags
> is usually a VERY VERY VERY etc. bad idea.

FWIW, if CVS had done that in 1.10.7 it would have saved me a lot
of pain back when that was current, and would not have interfered
with our operations in the slightest.  I think this is a really good
change.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

Re: Stale lock files with "anonymous" CVS

[David Wood]

Accessing with pserver. Server is 1.11.7. Client is WinCVS version 
1.3.13.1 (Beta 13 Build 1). Both are on Solaris 9. And this is the only 
problem I've found with this setup.

[EMAIL PROTECTED] (Larry Jones) wrote on 10/13/2003 11:49:37 AM:

> David Wood writes:
> > 
> > This does work as advertised, except that when a read-only user 
attempts 
> > to put a file where they shouldn't, we end up with a stale lock. Then 
no 
> > one can use the repository until it's manually removed.
> 
> Are you accessing the repository using client/server mode, or local
> mode?  What version(s) of CVS are you using?
> 
> -Larry Jones
> 
> I think your train of thought is a runaway. -- Calvin's Mom



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

Stale lock files with "anonymous" CVS

[David Wood]

We have a CVS repository here where some users have read only access 
except in a few directories, and the rest have read-write access 
everywhere.

This does work as advertised, except that when a read-only user attempts 
to put a file where they shouldn't, we end up with a stale lock. Then no 
one can use the repository until it's manually removed.

It seems that when the CVS process on our (Solaris 9) server has a 
permission problem, it dies without removing its lock files.

FYI, we are using a seperate lock directory. When CVS dies it gives the 
error:

cvs commit: ERROR: cannot write file 
/opt/cvs/repositories/primary/myproject/test/Attic/testfile2.html,v: 
Permission denied
Terminated with fatal signal 11

The read-write users map to user CVS. Read-only users map to user CVSR. 
Both belong to group CVS

Most files are rwx for user CVS, and r-x for group CVS. Directories where 
read-only users can write are rwx for user CVSR, and rwx for group CVS. 

I haven't found any information about this kind of problem over several 
days of searching. Given that the very popular anonymous CVS repositories 
around the world must use a similar technique, and such a condition would 
make them notoriously abusable (i.e. trivial, evil DOS attack), I assume I 
must be doing something wrong. 

Does anyone have any ideas?

Thanks,
-David


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

Re: pserver never starts running

[david]

> Hello all,
> I am having trouble with my cvs remote login.  It appears that my 
> pserver doesn't start running.
>
Under what circumstances?
 
> My OS is Redhat 9.0
> 
> It is running xinetd
> 
> My /etc/xinetd.d/cvspserver file looks like this
> 
> # default: off
> # description: An internal xinetd service, listing active services.
> service services
> {
> disable= no
> id= cvspserver
> env= HOME=/home/cvs
> port= 2401
> socket_type= stream
> protocol= tcp
> wait= no
> user= root
> passenv=
> server= /usr/bin/cvs
> server-args= --allow-root=/var/lib/cvsroot pserver
> }
> 
> When I type:
> telnet [host] 2401 from my windoze machine is says: "Connection to 
> [host]...Could not open a connection to host on port 2401 : Connect 
> failed.  ([host] is either jake or 192.168.0.155)
>
Have you rebooted or anything since putting this in cvspserver?
Or typed
kill -SIGUSR2 xinetd
as root, to get xinetd to reread its configuration files?

If you've done either of these, then I don't know what could be
going on.
 
David H. Thornley| If you want my opinion, ask.
[EMAIL PROTECTED]   | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-


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

Re: cvs-1.11.7 seems to have changed the api for "release"

[David Everly]

On Thu, Oct 02, 2003 at 03:32:43PM MDT, Derek Robert Price wrote:
> ~From the NEWS file:
> 
> | Changes from 1.11.6 to 1.11.7:
> 
> 
> . . .
> 
> | * The global '-l' option, which suppressed history logging, has been
> removed
> | from both client and server.

DOH!!  I read that but didn't put two and two together...thanks
for helping me throught my brain problems.  :)


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

cvs-1.11.7 seems to have changed the api for "release"

[David Everly]

Using pserver cvs-1.11.7 on solaris and client cvs-1.11.6 for aix,
hpux, or solaris, there is this problem which does not occur when
the client and server are the same version:

cvs release -d example

Protocol error: bad global option -l
cvs release: unable to release `example'

Thanks,
Dave.


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

[lawrence.jones@eds.com: Re: Stable CVS 1.11.7 Released! (Derek Robert Price)]

[David Everly]

Thanks Larry!  This fixed it.

--- Begin Message ---
David Everly writes:
> 
> All three have the same behavior of showing the password (which was
> not present with 1.11.6).  Output of "uname -a":
> 
>AIX chanegw0 3 4 000110554C00
>SunOS ndccsr02 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-Enterprise
>HP-UX chanhp9 B.11.11 U 9000/800 1877750441 unlimited-user license

By golly, so they do.  The GNULIB version of getpass is defective, but
it doesn't show up on my BSD-derived system nor, presumably, on Linux. 
Since passwords are read directly from the terminal, it's not tested in
the nightly testing.  I've checked in a fix and I'll be sending it on to
the GNULIB folks.  Here's a patch for anyone that wants it:

Index: getpass.c
===
RCS file: /cvs/ccvs/lib/getpass.c,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- getpass.c   29 Jul 2003 13:37:37 -  1.1.2.1
+++ getpass.c   30 Sep 2003 22:11:51 -  1.1.2.2
@@ -20,6 +20,9 @@
 #endif
 
 #include 
+#ifndef SEEK_CUR
+#define SEEK_CUR 1
+#endif
 #include 
 #include 
 #include "getline.h"
@@ -83,8 +86,11 @@
  /* Remove the newline.  */
  buf[nread - 1] = '\0';
  if (tty_changed)
-   /* Write the newline that was not echoed.  */
-   putc ('\n', out);
+   {
+ /* Write the newline that was not echoed.  */
+ if (out == in) fseek (out, 0, SEEK_CUR);
+ putc ('\n', out);
+   }
}
 }
 
-Larry Jones

I sure like summer vacation. -- Calvin

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

Re: Stable CVS 1.11.7 Released! (Derek Robert Price)

[David Everly]

On Tue, Sep 30, 2003 at 03:10:08PM MDT, Larry Jones wrote:
> David Everly writes:
> > 
> > (Password is not displayed while typing it, but is displayed after
> > pressing the ENTER key.)
> 
> On what platform?
> 
> -Larry Jones

All three have the same behavior of showing the password (which was
not present with 1.11.6).  Output of "uname -a":

   AIX chanegw0 3 4 000110554C00
   SunOS ndccsr02 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-Enterprise
   HP-UX chanhp9 B.11.11 U 9000/800 1877750441 unlimited-user license

Configure parameters:

   ./configure --prefix=/opt/cvs-1.11.7 --without-krb4 --without-gssapi

I am assuming this has something to do with the new internal getpass
function...but not sure what.



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

RE: Stable CVS 1.11.7 Released! (Derek Robert Price)

[David Everly]

Under cvs-1.11.7, the password is displayed on the client screen
as follows:

cvs login

(Password is not displayed while typing it, but is displayed after
pressing the ENTER key.)

I know pserver in general is not very secure, but is there any
way to have a patch or fix that might eliminate this display?

Thanks,
Dave.
--

http://agilemanifesto.org/principles.html

()  ascii ribbon campaign - against html mail
/\- against proprietary attachments

For assistance, see:  http://www.expita.com/nomime.html



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

Re: Countering the usual diatribe against binary files, was Re: cvs diff, proposal for change

[david]

> On Tue, 2003-09-09 at 14:53, Greg A. Woods wrote:
> > [ On Tuesday, September 9, 2003 at 10:10:46 (-0400), Tom Copeland wrote: ]
> > > Subject: Re: Countering the usual diatribe against binary files, was Re:  cvs 
> > > diff, proposal for change
> > >
> > > Hm.  Do CVS branches not work right with binary files?
> > 
> > It depends on what you mean by "work".  Merging branches containing
> > binary files is one heck of a lot more work.
> 
> Cool, yup, right, merging binary files isn't going to happen. 
>
Isn't going to happen with any other version control system I know of,
either, which is why I don't see why CVS should be bad for binary
files.  It isn't going to buy you much over a simpler solution, but
I don't see that it will cost anything, assuming that CVS is already
set up.  I wouldn't use CVS just to store binary files, but I would
and have happily used it to store binary files associated with
text files.
 
-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

Countering the usual diatribe against binary files, was Re: cvs diff, proposal for change

[David Clunie]

Greg A. Woods wrote:

1. keep your binary files in a separate manually managed archive.
...
"CVS supports binary files"?!?!?!?  No, I don't think so.  The '-kb'
"sticky flag" is just a terribly bad hack that gets more people into
more trouble with CVS than you could ever imagine because it gets
mis-interpreted as doing what you think it does.  It was not intended
for that purpose at all and it does not work the way you think it does.
DO NOT try to store binary files in CVS.
[EMAIL PROTECTED] wrote:

> We are currently storing gigabytes of binary data files in our CVS
> repository along with lots of text data.  We have found that if you
> remember to cvs add -kb from Windows (mandatory) or Unix (recommended),
> or to mark the files as binary after check-in under Unix *before* the
> first-ever modification is made, it can cope.  At the cost of
> performance penalties.
>
> But reading the above I'm wondering whether there's some other danger
> that we're unaware of, that would make us change our current methods.
>
> I've read the FAQ section on binary files, and found nothing there that
> I/we weren't already aware of.
We have several terabytes of binary files stored in a CVS repository.

Whether it be a "terrible hack", or a "misuse" of the tool, it seems
to work sufficiently well to get the job done.
We are not interested in merges, or diffs, or concurrency, we just
want the versioning and the log of "who, what, when and why" that
lives in the ,v files.
We don't care that inside they are not stored as deltas, we don't
care that each version is stored as all bytes in their entirety, we
just keep buying more shelves of disks in the arrays.
It would be nice if it were faster, but it is fast enough to meet
our requirements.
Going back to doing this manually would be a nightmare, a totally
untenable suggestion bordering on ludicrous.
Until there is a good, free, binary file version control system,
then cvs, with all its known limitations, fits the bill.
The "-kb" flag is the greatest thing since sliced bread, apart from
the long forgotten versioning file system of VMS that might also have
been a suitable solution for us.
If there is something "undesirable" going on inside CVS that is problematic,
I would be interested to know, but the empirical evidence would tend to
suggest otherwise.
david

PS. With respect to the original thread, since our binary files are
a) of a specific format, and b) we have tools equivalent to diff that
do comparisons of the content (for the purpose of human comparison
but not automatic editing or patching), yes it would be nice to be able to
parameterize or configure the type of diff used, without any expectation
that there would be any corresponding storage using "deltas" inside,
if these two operations are indeed separable.


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

Re: Cannot add file on non-branch tag

[david]

> Hi All
> 
> I am trying to add a file on a following specific path on a branch named
> "bname"
> Though I am able to add a file on some other location path.
> The error  is - 
> 
> cvs server: cannot add file on non-branch tag bname
> 
> I have checked the other files existing on this path are branched, infact
> added after branching.
> 
It would appear that "bname" is not a branch on that particular file,
but rather a revision tag.  CVS maintains information by file, and
so it is entirely possible (and usually a problem) to have a tag be
a branch tag on one file and a revision tag on another.

You can check this with "cvs stat -v ", which will show
you all the tags and whether they are branch or revision.  (You can
do the same with "cvs log", but it's harder to spot the difference.)

To fix this, eliminate the existing "bname" tag, and recreate it as
a branch tag.  Then check with "cvs stat" to see what the sticky
tag is, and "cvs update -r bname " if it is wrong.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

Re: Checking out without lock

[david]

> I have read access to the CVS repository but no write access.
> Obviously this means I cannot commit any changes.  But it ought to be
> possible to get a checkout.  However even if I turn off history
> logging, cvs co won't work because it wants to make a lock file.
> 
> Is there some option similar to -l to say do not make lock files when
> reading?  This means you could get an inconsistent checkout when
> someone updates the repository while you're reading, but that is a
> risk anyway for projects with more than one directory, and a risk I'm
> willing to take.
> 
Not that I know of.

The correct solution is for the administrator to set up separate
lock directories, with a line like
LockDir=/usr/cvs/cvslocks
in the CVSROOT/config file.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]




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

Re: pserver handle multiple requets?

[david]

> hi,
>  can pserver handle multiple requests(say 15 - 20) at the same 
> time?
> 
Always did whan I was administering it.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

RE: tools for deleting the expanded $Log$ comments

[David]

Zieg,

Thanks for your code, I have tested we the example file I am sending to you,
but it prints me the followin message: "No RCS-formatted logs were found!" I
don't know why because I have such logs comments.

I have tested it under:

This is perl, v5.6.1 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)

Copyright 1987-2001, Larry Wall

Binary build 631 provided by ActiveState Tool Corp.
http://www.ActiveState.com
Built 17:16:22 Jan  2 2002

Thanks in advance for any help,

David


-Mensaje original-
De: Zieg, Mark [mailto:[EMAIL PROTECTED]
Enviado el: miércoles, 06 de agosto de 2003 15:08
Para: David; Info-Cvs
Asunto: RE: tools for deleting the expanded $Log$ comments


> I would like to know if there is a tools (in perl for example)
> that delete all the $Log$ expanded comments. Sometimes it is
> useful because your classes have revisions for a given project,
> but if you decide to eliminate from all your code the inserted
> log comments for a given new revision, or because your are using
> your class on another project.

Yuck...but I've been there.  It's an ugly situation, but sometimes
management comes up with pretty ugly mandates.

You may need to tweak this to work on your coding/comment conventions, but
it worked on a bit of C code I ran it against:

#!/usr/bin/perl -w


#
#
#   StripRcsLog.pl
#
#
#


#
#
#  Description:Attempts to strip RCS/CVS-inserted "$Log$" comments from
a  #
#  text file.
#
#
#
#  Author: Mark Zieg <[EMAIL PROTECTED]>
#
#
#
#  Usage:  StripRcsLog.pl < commented.c > stripped.c
#
#
#
#  WARNING:THIS IS DANGEROUS.  The algorithm is not foolproof.
#
#  Manual verification of cleaned code is highly
recommended!  #
#  (Of course, you'd only be using this script if you kept
#
#  all your code under revision-control...:-)
#
#
#



MAIN:
{
my $State = "BEFORE_LOG";
my $Prefix;
while( my $Line =  )
{
if( $State eq "BEFORE_LOG" )
{
if( $Line =~ /^(.*)\$Log.*\$/ )
{
$State = "IN_LOG";
$Prefix = $1;
$Prefix =~ s/\*/\\*/g;  # If you understand the need for
this,
}   # you get your Perl badge for the
day!
else
{
print $Line;
}
}
elsif( $State eq "IN_LOG" )
{
if( $Line =~ /^$Prefix/ )
{
# looks like a follow-on log line;
# do nothing, and thus delete line
}
else
{
# looks like the prefix has changed, so
# assUme we've ended the log section
print $Line;
$State = "AFTER_LOG";
}
}
elsif( $State eq "AFTER_LOG" )
{
print $Line;
}
else
{
die( "Invalid state: $State\n" );
}
}
if( $State eq "BEFORE_LOG" )
{
warn( "No RCS-formatted logs were found!" );
}
elsif( $State eq "IN_LOG" )
{
warn( "The log parser consumed the entire file!  Probable script
error!" );
}
}


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

Re: how to really remove the information of the file?

[david]

> When you remove a file from the repository you actually mark it as dead, 
and it stays in the repository.. Therefore the upcount in revision numbers.
>
Yes.  CVS has no way to distinguish between two different files with the
same names and the same location in the directory structure.
  
> I think the way to permanently delete a file is to to it "hard" and without 
using cvs-commands (in Unix use rm) That is if you are clear with that the 
file and all previous revisions will forever be gone. You also have to have 
access to removing files from the cvsroot. 
>
Right.  If you go to the repository and delete the file there
corresponding to the offending file but having ",v" appended to the
end, it's gone forever.

This is something to be very careful of.  By doing that, you break the
repository for any time before the file was marked dead or removed,
and you lose that file permanently.  This is normally exactly what
you don't want in a version control system.

And what you get by this is a different revision number.  This doesn't
matter.  You cannot map revision numbers to much of anything else
successfully without putting in a lot of pointless work, and so you
are almost always much better off treating the revision numbers
as "magic cookies".

When you want to have a coherent setup of the file system that you can
refer to later, use tags.  That's what they're there for.

Revision numbers are for CVS.
Tags are for humans.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



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

tools for deleting the expanded $Log$ comments

[David]

Hello members,

I would like to know if there is a tools (in perl for example) that delete
all the $Log$ expanded comments. Sometimes it is usefull because your
classes have revisions for a given project, but if you decide to eliminate
from all your code the inserted log comments for a given new revision, or
because your are using your class on another project.

Do you have any suggestion about how to handle such situation. For example I
would like to replace the expanded comments by $Log$, becase I wanto to use
such source files on another project.

Thanks in advance,

David



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