linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Kent Borg <kentborg@borg.org>
To: Tom Rini <trini@kernel.crashing.org>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: BK to CVS?
Date: Thu, 4 Oct 2001 09:25:12 -0400	[thread overview]
Message-ID: <20011004092511.A3914@borg.org> (raw)
In-Reply-To: <20011003113245.B18196@cpe-24-221-152-185.az.sprintbbd.net>; from trini@kernel.crashing.org on Wed, Oct 03, 2001 at 11:32:45AM -0700


On Wed, Oct 03, 2001 at 11:32:45AM -0700, Tom Rini wrote:
> Doing this daily isn't too horrid.  Use the rsync version and tag
> a tree daily.  Thats more or less what I do.

I might switch to that.

But won't I still have a problem of our cvs expanding keywords
breaking the next patch that gets too near them?

> Yeap.  One thing you can try is to un-export the keywords first.  Ie
> change them back into BK Id: %x% %..%

I don't understand.

> Smaller hunks and change 'em back into the unexported form?

Again I don't think I understand what you mean by "unexported form".


Right now I am burning plenty of computrons and rattling the disk a
lot (let's hear it for otherwise idle machines) by exporting two
complete trees, running a slow perl script over both to remove
expansions of dollar-Id, and now dollar-Revision, make my own diff
-Nru of that, and then I guess I will have to patch by hand a zillion
annoying recent changes to the placement dollar-Id in sparc64 files.
And then I will tackle whatever I discover is still not patching after
my modified perl script finishes running.

I am starting to think that trying to run a shadow source code
controlled repository is a mistake.  Am I dragging along unadvisable
mental baggage from the old days of developing proprietary code?  Do I
need to take a deep breath here, hold my nose, have faith in The
Source, and leap??  Am I foolishly fighting Bitkeeper by trying to
stick with cvs internally?  Do I need to just give in on Bitkeeper?


Thanks,


-kb, the Kent who is coming to hate source code control system
keywords with more and more authority each day.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2001-10-04 13:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-03 17:05 BK to CVS? Kent Borg
2001-10-03 18:32 ` Tom Rini
2001-10-04 13:25   ` Kent Borg [this message]
2001-10-04 20:29     ` Tom Rini
2001-10-05 15:11       ` Kent Borg
2001-10-05 15:48         ` Andrew Johnson
2001-10-05 16:04           ` Ricardo Scop
2001-10-06  2:25             ` Dan Malek
2001-10-05 20:52               ` BK to CVS? + MDIO Ricardo Scop
2001-10-06  3:34                 ` Tom Rini
2001-10-06  3:42                   ` Re[2]: " Ricardo Scop
2001-10-06  3:41                 ` Dan Malek
2001-10-08 12:01                 ` Jerry Van Baren
2001-10-08 13:06                   ` Wolfgang Denk
2001-10-06  2:43               ` BK to CVS? Tom Rini
2001-10-05 16:23           ` Kent Borg
2001-10-05 16:42             ` Andrew Johnson

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=20011004092511.A3914@borg.org \
    --to=kentborg@borg.org \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=trini@kernel.crashing.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 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 NNTP newsgroup(s).