* [setup] Extra files under source control @ 2008-07-09 1:54 Charles Wilson 2008-07-09 2:11 ` Brian Dessent 0 siblings, 1 reply; 5+ messages in thread From: Charles Wilson @ 2008-07-09 1:54 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [setup] Extra files under source control 2008-07-09 1:54 [setup] Extra files under source control Charles Wilson @ 2008-07-09 2:11 ` Brian Dessent 2008-07-19 16:13 ` Charles Wilson 0 siblings, 1 reply; 5+ messages in thread From: Brian Dessent @ 2008-07-09 2:11 UTC (permalink / raw) To: Charles Wilson; +Cc: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [setup] Extra files under source control 2008-07-09 2:11 ` Brian Dessent @ 2008-07-19 16:13 ` Charles Wilson 2008-07-23 2:01 ` Charles Wilson 0 siblings, 1 reply; 5+ messages in thread From: Charles Wilson @ 2008-07-19 16:13 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [setup] Extra files under source control 2008-07-19 16:13 ` Charles Wilson @ 2008-07-23 2:01 ` Charles Wilson 2008-07-23 13:35 ` Dave Korn 0 siblings, 1 reply; 5+ messages in thread From: Charles Wilson @ 2008-07-23 2:01 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [setup] Extra files under source control 2008-07-23 2:01 ` Charles Wilson @ 2008-07-23 13:35 ` Dave Korn 0 siblings, 0 replies; 5+ messages in thread From: Dave Korn @ 2008-07-23 13:35 UTC (permalink / raw) To: 'Mailing List: CygWin-Apps' 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.... ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-07-23 13:35 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-07-09 1:54 [setup] Extra files under source control Charles Wilson 2008-07-09 2:11 ` Brian Dessent 2008-07-19 16:13 ` Charles Wilson 2008-07-23 2:01 ` Charles Wilson 2008-07-23 13:35 ` Dave Korn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).