All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ang <mang@subcarrier.org>
To: parisc-linux@parisc-linux.org
Subject: Re: [parisc-linux] CVS rumors
Date: Thu, 12 Jul 2001 00:42:25 -0400	[thread overview]
Message-ID: <3B4D2AB1.5010809@subcarrier.org> (raw)
In-Reply-To: E15K1Iz-0002RR-00@noam.fc.hp.com

Paul Bame wrote:

>
> CM best practices usually involve explicitly tagging any release one
> hopes to reproduce in the future and we could start doing that (I recommend
> it).  For now either we apply the aforementioned workaround so we can
> do untagged date-based checkouts, or I can come up with a procedure for
> grabbing a suitable set of bits.


Tags are cheap.  Explicitly tagging at important moments is the way to 
go.  Relying on a date-based checkout is potentially less accurate, so 
IMO this shouldn't be the common practice.  There's no harm in adding a 
static tag, and you can always remove it or possibly fix it up if you 
get it wrong.


> = I don't understand why we're using vendor branches at all though.  When
> = mang was doing CVS God duties, he imported Linus' stuff on an ordinary
> = branch.  What is the advantage of using vendor branches over ordinary ones?
> 
> Vendor branches are both a concept and an implementation.  The
> implementation sucks but the concept -- keeping clean upstream releases
> on a separate branch -- to me is a good one and is one of the things
> CVS does quite well.
> 
> safe-cvsimport essentially doesn't use the vendor branch *implementation*
> (aka, how 'cvs import' would do it) but it does use the vendor branch
> *concept*.  So safe-cvsimport is attempting to automate what mang did
> by hand.


Writing an import script was one of those things I always meant to do in 
my copious spare time.  I'm glad to see that someone is actually doing 
the work :)  Where does the code for safe-cvsimport live?


> = > For now I'll be
> = > happy to consult and/or fix problems which result from safe-cvsimport.
> = 
> = No offence, but every time we've done a new import, we've discovered new
> = and excitingly different problems which have taken some time to be fixed.


All the more reason to roll the solutions found to these problems into a 
script.  Proper importing by hand is rather tedious and prone to 
operator error.  Also, any extra time spent fully understanding the 
problems and finding a robust solution will be regained over the 
following merges or if the cvs wrangler moves on to a different project 
-- hypothetically, of course ;)

> = I'm extremely nervous about using it while you're gone.
> 
> In the linux tree I echo your concern and there's really no way to be
> rid of the vestiges of upstream imports which came into the trunk unless
> we reinitialize our archive.  That plus the current brokenness of not
> removing files which were removed upstream makes me think that
> unless I do future imports, they might better be done "by
> hand" on the "linus" branch, which I call a vendor branch though it
> is not a cvs-style-broken-vendor-branch any longer.


I'd avoid using the term "vendor branch", since that already has a 
specific meaning to savvy CVS users (who will rightly criticize their 
use).  Calling it something like the "upstream branch" would avoid the 
overloaded meaning.  I haven't been following things enough to know what 
the issues related to "the vestiges of upstream imports" are.

	- Mike.

  reply	other threads:[~2001-07-12  7:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-10 15:08 [parisc-linux] CVS rumors Paul Bame
2001-07-10 16:25 ` Matthew Wilcox
2001-07-10 17:28   ` Paul Bame
2001-07-12  4:42     ` Michael Ang [this message]
2001-07-12 15:30       ` Paul Bame
2001-07-12 15:01         ` Michael Ang
2001-07-12 18:30           ` Paul 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=3B4D2AB1.5010809@subcarrier.org \
    --to=mang@subcarrier.org \
    --cc=parisc-linux@parisc-linux.org \
    /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.