Re: linux bame

Re: linux bame

[Matthew Wilcox]

On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote:
>     Somebody never imported 2.4.0-test6, then I imported -test10 on the main
>     vendor branch and now can't (easily) undo that to import test6 and THEN
>     test10.  This workaround sucks.

don't use vendor branches.  didn't you talk to mang about this?

-- 
Revolutions do not require corporate support.

Re: linux bame

[bame]

= On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote:
= >     Somebody never imported 2.4.0-test6, then I imported -test10 on the mai
n
= >     vendor branch and now can't (easily) undo that to import test6 and THEN
= >     test10.  This workaround sucks.
= 
= don't use vendor branches.  didn't you talk to mang about this?

Um, I have no information to go on from your note.  All the (successful)
merges I've done before have used the cookbook CVS merge method including
a vendor branch.  Several (N-1?) of the palinux merges have been
accompanied by updating the vendor branch.  And this merge is going
well despite the ugly workaround, or so it appears to me.  Just
importing files to a vendor branch should have no effect on anything
else unless CVS has some horrible bug (RCS does not).  Before I make
what is apparently a serious mistake ("don't use vendor branches" sounds
pretty serious) please enlighten me!

	-P

Re: linux bame

[Michael Ang]

bame@riverrock.org wrote:
> 
> = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote:
> = >     Somebody never imported 2.4.0-test6, then I imported -test10 on the mai
> n
> = >     vendor branch and now can't (easily) undo that to import test6 and THEN
> = >     test10.  This workaround sucks.

If the sources on the linus branch have been religiously tagged every
time they're updated, then reverting to a previous would have been
relatively painless.  I'm not sure what "this workaround" was, but I
guess at this point test10 is merged so the point is moot.

> = don't use vendor branches.  didn't you talk to mang about this?
> 
> Um, I have no information to go on from your note.  All the (successful)
> merges I've done before have used the cookbook CVS merge method including
> a vendor branch.  Several (N-1?) of the palinux merges have been
> accompanied by updating the vendor branch.  And this merge is going
> well despite the ugly workaround, or so it appears to me.  Just
> importing files to a vendor branch should have no effect on anything
> else unless CVS has some horrible bug (RCS does not).  Before I make
> what is apparently a serious mistake ("don't use vendor branches" sounds
> pretty serious) please enlighten me!

Vendor branches are evil.  (When I say "vendor branch" I mean the
special kind of branch created by "cvs import".)  When you check in to a
vendor branch your changes will also be seen on the trunk, *unless* that
file has been previously modified on the trunk.  This is almost never
what you want and adds confusion during merging (when you least want
it).  Tracking third-party sources using a normal branch, as we are
doing, is much simpler and gives you more control.

When I did the original import of Linus' sources I converted the vendor
branch to a normal branch using cvs admin magic.  So none of the
annoyances of vendor branches should affect us, as long as any new files
are added on the linus branch using "cvs add", NOT "cvs import".

When you say you "I imported -test10 on the main vendor branch" I hope
you really mean that you used "cvs add" on the linus branch.  From your
other messages, your tags looked good.

	- Mike.

Re: linux bame

[Paul Bame]

= bame@riverrock.org wrote:
= > 
= > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote:
= > = >     Somebody never imported 2.4.0-test6, then I imported -test10 on the
 mai
= > n
= > = >     vendor branch and now can't (easily) undo that to import test6 and 
THEN
= > = >     test10.  This workaround sucks.
= 
= If the sources on the linus branch have been religiously tagged every
= time they're updated, then reverting to a previous would have been
= relatively painless.  I'm not sure what "this workaround" was, but I
= guess at this point test10 is merged so the point is moot.

Like the comment said, there was no copy of plain -test6 in CVS (that I
saw).  Without -test6 in CVS it's much harder to use cvs diff to figure
out the right way to merge files when there are conflicts.
I didn't realize this until -test10 was already there, so I *then*
brought in -test6.  They're in the wrong order on the 1.1.1 branch, so
the standard merge command 'cvs -jlinus:yesterday -jlinus:<newest>'
won't work next time -- explicit names will be required.

= Vendor branches are evil.  (When I say "vendor branch" I mean the
= special kind of branch created by "cvs import".)  When you check in to a
= vendor branch your changes will also be seen on the trunk, *unless* that
= file has been previously modified on the trunk.

Thanks for clarifying what "evil" means!  That is pretty ugly indeed!

= This is almost never
= what you want and adds confusion during merging (when you least want
= it).  Tracking third-party sources using a normal branch, as we are
= doing, is much simpler and gives you more control.

But I've seen no cook book for it.  I'm guessing that instead of cvs import
you use:
	cvs co -rlinus linux
	<unpack new linux bits on top of linux>
	cd linux
	cvs commit (make note of new files from commit)
	cvs add <new files>
	cvs commit
	cvs tag LINUS_NEW_REVISION
perhaps with provision for removing obsolete files too.  I suppose that is
simpler than a single cvs import command from a certain perspective :-)

= When I did the original import of Linus' sources I converted the vendor
= branch to a normal branch using cvs admin magic.  So none of the
= annoyances of vendor branches should affect us, as long as any new files
= are added on the linus branch using "cvs add", NOT "cvs import".

Have you a pointer to the magic or the knowledge to recreate it?  I
had no idea there was a special RCS marking for the evil type of branch.

= When you say you "I imported -test10 on the main vendor branch" I hope
= you really mean that you used "cvs add" on the linus branch.  From your
= other messages, your tags looked good.

I used "cvs import", and either your branch magic worked, or I finished the
merge before anybody randomly updated from cvs.  Since import used 1.1.1,
which is the branch you "fixed", it seems possible that 'cvs import' might
be rendered harmless but I don't know that for sure.

	-P

[parisc-linux] tracking third-party sources (was Re: linux bame)

[Michael Ang]

Paul Bame wrote:
> 
> = bame@riverrock.org wrote:
> = >
> = > = On Thu, Nov 09, 2000 at 03:53:48PM -0700, Paul Bame wrote:
> = > = >     Somebody never imported 2.4.0-test6, then I imported -test10 on the
>  mai
> = > n
> = > = >     vendor branch and now can't (easily) undo that to import test6 and
> THEN
> = > = >     test10.  This workaround sucks.
> =
> Like the comment said, there was no copy of plain -test6 in CVS (that I
> saw).  Without -test6 in CVS it's much harder to use cvs diff to figure
> out the right way to merge files when there are conflicts.
> I didn't realize this until -test10 was already there, so I *then*
> brought in -test6.  They're in the wrong order on the 1.1.1 branch, so
> the standard merge command 'cvs -jlinus:yesterday -jlinus:<newest>'
> won't work next time -- explicit names will be required.

The best thing to do is to import -test10 again and move the static tag
by re-tagging.

> = Tracking third-party sources using a normal branch, as we are
> = doing, is much simpler and gives you more control.
> 
> But I've seen no cook book for it.  I'm guessing that instead of cvs import
> you use:
>         cvs co -rlinus linux
>         <unpack new linux bits on top of linux>
>         cd linux
>         cvs commit (make note of new files from commit)
>         cvs add <new files>
>         cvs commit
>         cvs tag LINUS_NEW_REVISION
> perhaps with provision for removing obsolete files too.  I suppose that is
> simpler than a single cvs import command from a certain perspective :-)

I had a good chat with Paul about this, and we worked out that using
"import" is marginally better.

This is what the add/remove method would look like:
cvs co -rlinux linux
<unpack new linux bits>
<rm files in dir not in tarball>
cvs rm <rm'ed files>
cvs add <new files>
cvs commit
cvs tag LINUS_NEW_REVISION

Add the import method:
<unpack new linux bits>
cd linux
cvs import linux linus LINUS_NEW_REVISION
cvs admin -b <new files>

> = When you say you "I imported -test10 on the main vendor branch" I hope
> = you really mean that you used "cvs add" on the linus branch.  From your
> = other messages, your tags looked good.
> 
> I used "cvs import", and either your branch magic worked, or I finished the
> merge before anybody randomly updated from cvs.  Since import used 1.1.1,
> which is the branch you "fixed", it seems possible that 'cvs import' might
> be rendered harmless but I don't know that for sure.

Using "import" to bring in new files taints them with the vendor branch
badness.  These files should be adjusted using "cvs admin -b".  Note
that "cvs admin" works directly on files in the repository at low level
(without any revisioning of changes) and is thus to be avoided if at all
possible.  Please don't run "cvs admin" if you (the collective "you")
don't know the consequences.

	- Mike.

Re: linux bame

[Matthew Wilcox]

On Wed, Jan 10, 2001 at 02:08:27PM -0700, Paul Bame wrote:
> Log message:
> First-pass attempt at /proc/config, mostly from grant.  Seems to work
> fine with 'cat', but 'tail' and 'wc' aren't reliable with my userspace.

umm.  this has often been discussed for addition to the standard linux
kernel, but linus has not yet taken patches to do so.  i suggest searching
linux-kernel archives to see the arguments, i got bored and didn't read
them so i can't summarise.  i don't think this is something we should
be adding.

tail and wc invariably don't work on /proc files.  neither does less.
this is pretty inherent to the design of /proc and not a reflection on
your code.

> NOTE THIS IS ONLY VISIBLE on the proc_config branch.

it might be better to let this branch wither...

-- 
Revolutions do not require corporate support.

Re: linux bame

[Matthew Wilcox]

On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote:
> CVSROOT:	/home/cvs/parisc
> Module name:	linux
> Changes by:	bame	00/11/01 13:53:24
> 
> Modified files:
> 	include/asm-parisc64: posix_types.h 
> 
> Log message:
> Don't need a separate copy of this one either

err.. are you sure?  we used to get a lot of prototype problems when they
were the same file.  what's changed that they're now able to be the same?

-- 
Revolutions do not require corporate support.

Re: linux bame

[bame]

= On Wed, Nov 01, 2000 at 01:53:24PM -0700, Paul Bame wrote:
= > CVSROOT:	/home/cvs/parisc
= > Module name:	linux
= > Changes by:	bame	00/11/01 13:53:24
= > 
= > Modified files:
= > 	include/asm-parisc64: posix_types.h 
= > 
= > Log message:
= > Don't need a separate copy of this one either
= 
= err.. are you sure?  we used to get a lot of prototype problems when they
= were the same file.  what's changed that they're now able to be the same?

I changed the parisc version so that the data types would compile to
the same size in both wide and narrow mode.  Unfortunately there is
at least one issue which will probably require this scheme to change :-(

	-P