[setup] Extra files under source control

[setup] Extra files under source control

[Charles Wilson]

It seems to me that the following files:

libgcrypt/Makefile.in
libgcrypt/aclocal.m4
libgcrypt/cipher/Makefile.in
libgcrypt/configure
libgcrypt/doc/Makefile.in
libgcrypt/doc/gcrypt.info
libgcrypt/doc/stamp-vti
libgcrypt/doc/version.texi
libgcrypt/m4/Makefile.in
libgcrypt/mpi/Makefile.in
libgcrypt/src/Makefile.in
libgcrypt/tests/Makefile.in
libgpg-error/Makefile.in
libgpg-error/aclocal.m4
libgpg-error/configure
libgpg-error/lang/Makefile.in
libgpg-error/lang/cl/Makefile.in
libgpg-error/m4/Makefile.in
libgpg-error/src/Makefile.in
libgpg-error/tests/Makefile.in

which are under source control in the setup repository really should 
/not/ be stored in CVS.  They are regenerated every time you run 
doconfigure, anyway.

If nobody objects for a week, I'll remove them from CVS Tuesday 15 Jul.

--
Chuck

Re: [setup] Extra files under source control

[Brian Dessent]

Charles Wilson wrote:

> which are under source control in the setup repository really should
> /not/ be stored in CVS.  They are regenerated every time you run
> doconfigure, anyway.

It makes sense to not have them in CVS from a consistency standpoint. 
However, those dirs are intended to be vendor branches (or whatever CVS
calls it when you just bulk add external files) so that hopefully
keeping a current version just means importing an upstream release
tarball.  I don't know how CVS copes with that, I'd have to read up in
the CVS book.  Dave, do you know?

Brian

Re: [setup] Extra files under source control

[Charles Wilson]

Brian Dessent wrote:
> Charles Wilson wrote:
> 
>> which are under source control in the setup repository really should
>> /not/ be stored in CVS.  They are regenerated every time you run
>> doconfigure, anyway.
> 
> It makes sense to not have them in CVS from a consistency standpoint. 
> However, those dirs are intended to be vendor branches (or whatever CVS
> calls it when you just bulk add external files) so that hopefully
> keeping a current version just means importing an upstream release
> tarball.  I don't know how CVS copes with that, I'd have to read up in
> the CVS book.  Dave, do you know?

Brian, as Dave never answered, does this constitute an objection, or can 
I go ahead and remove the listed files?

--
Chucj

Re: [setup] Extra files under source control

[Charles Wilson]

Charles Wilson wrote:
> Brian Dessent wrote:
>> Charles Wilson wrote:
>>
>>> which are under source control in the setup repository really should
>>> /not/ be stored in CVS.  They are regenerated every time you run
>>> doconfigure, anyway.
>>
>> It makes sense to not have them in CVS from a consistency standpoint. 
>> However, those dirs are intended to be vendor branches (or whatever CVS
>> calls it when you just bulk add external files) so that hopefully
>> keeping a current version just means importing an upstream release
>> tarball.  I don't know how CVS copes with that, I'd have to read up in
>> the CVS book.  Dave, do you know?
> 
> Brian, as Dave never answered, does this constitute an objection, or can 
> I go ahead and remove the listed files?

 From here:
http://www.cs.utah.edu/dept/old/texinfo/cvs/cvs_toc.html#SEC43

it looks like you bulk import the third-party sources using the import 
command, and they automatically go onto the vendor branch (*not* HEAD). 
Then, on HEAD, you can make whatever mods you need -- such as removing 
superfluous generated files, like Makefile.in.

Then, when it's time to update the third party sources, you import in 
bulk again, using a different release tag. However, these will still 
automatically go onto the vendor branch, *not* HEAD.

quoting:
"For files that have not been modified locally, the newly created 
revision becomes the head revision. If you have made local changes, 
import will warn you that you must merge the changes into the main 
trunk, and tell you to use `checkout -j' to do so."

So, if you've removed some of the files on HEAD, I *think* they will 
stay removed on HEAD after you do a merge. However, if the 
newly-imported code has some additional files (an added directory with a 
new Makefile.in?) that should be removed from HEAD, you'd have to do 
that, on HEAD, manually after the merge.

--
Chuck

RE: [setup] Extra files under source control

[Dave Korn]

Charles Wilson wrote on 23 July 2008 03:01:

> Charles Wilson wrote:
>> Brian Dessent wrote:
>>> Charles Wilson wrote:
>>> 
>>>> which are under source control in the setup repository really should
>>>> /not/ be stored in CVS.  They are regenerated every time you run
>>>> doconfigure, anyway.
>>> 
>>> It makes sense to not have them in CVS from a consistency standpoint.
>>> However, those dirs are intended to be vendor branches (or whatever CVS
>>> calls it when you just bulk add external files) so that hopefully
>>> keeping a current version just means importing an upstream release
>>> tarball.  I don't know how CVS copes with that, I'd have to read up in
>>> the CVS book.  Dave, do you know?
>> 
>> Brian, as Dave never answered, does this constitute an objection, or can
>> I go ahead and remove the listed files?

  Sorry for taking a while to get to this one.  I have no objection as long
as you give it some thorough testing.  Any import-related problems can be
dealt with as they arise, we don't anticipate having to update the crypto
code often.
 
>  From here:
> http://www.cs.utah.edu/dept/old/texinfo/cvs/cvs_toc.html#SEC43

  Yeah.... that's how it's supposed to work in theory, but then CVS goes and
does this screwy thing of making the vendor branch the default revision for
all the imported files, instead of trunk...  which means that when you
checkout a fresh sandbox you get r1.1 of your own files and r1.1.1.1 of the
imported files and any edits you apply will be committed against the vendor
branch and you'll get conflicts when you try to merge and meanwhile when you
import a new version CVS merges any new files straight across to trunk
leaving it in a godawful mess of old and new files that still needs a merge
and then a bunch of conflicts resolved before you can even do anything with
it and by the way did I mention that cvs on /src went all screwy every time
I did a branch and I had to go in and fix cache files?  I did?  Well anyway
where was I oh yes and anyway you get this terrible mixed up checkout with
intertwined bits of branch and trunk and ...

  I guess what I'm saying is "I'd really like it if we could run 'cvs admin
-b' on the imported files, is that possible?"
 

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....