All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ang <mang@subcarrier.org>
To: bame@riverrock.org
Cc: parisc-linux@thepuffingroup.com
Subject: Re: linux bame
Date: Tue, 14 Nov 2000 14:17:35 -0500	[thread overview]
Message-ID: <3A118FCF.9C7EEEBF@subcarrier.org> (raw)
In-Reply-To: m13uGYm-001Vp3C@chalet

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.

  reply	other threads:[~2000-11-14 19:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200011092253.PAA14963@puffin.external.hp.com>
2000-11-10  9:49 ` linux bame Matthew Wilcox
2000-11-10 15:57   ` bame
2000-11-14 19:17     ` Michael Ang [this message]
2000-11-14 20:00       ` Paul Bame
2000-11-14 22:31         ` [parisc-linux] tracking third-party sources (was Re: linux bame) Michael Ang
     [not found] <200101102108.OAA19847@puffin.external.hp.com>
2001-01-10 23:31 ` linux bame Matthew Wilcox
     [not found] <200011012053.NAA15579@puffin.external.hp.com>
2000-11-02  0:13 ` Matthew Wilcox
2000-11-02  6:18   ` bame

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A118FCF.9C7EEEBF@subcarrier.org \
    --to=mang@subcarrier.org \
    --cc=bame@riverrock.org \
    --cc=parisc-linux@thepuffingroup.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.