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.
next prev parent 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.