From: Dan Kegel <dkegel@ixiacom.com>
To: "linuxppc-embedded@lists.linuxppc.org"
<linuxppc-embedded@lists.linuxppc.org>
Cc: dank@kegel.com
Subject: bitkeeper, the 2_4_devel tree, and branches
Date: Mon, 20 May 2002 17:35:15 -0700 [thread overview]
Message-ID: <3CE99643.B7188518@ixiacom.com> (raw)
My naive assumption, looking at the changesets listed at
http://ppc.bkbits.net:8080/linuxppc_2_4_devel/
was that if I cloned the repository as of two adjacent
changesets, and exported from those repositories,
the result would differ by exactly the second changeset.
That's probably true at some level, but when I tried
it with the two tags 1.899 and v2.4.18 (aka 1.2.2.131),
which are adjacent in the changeset list on that web page,
I got two entirely different trees. It seems many branches
exist in the linuxppc_2_4_devel tree, and that bk names
branches using the godawful SCCS/CVS branch naming scheme.
(Hrmf- after getting used to Perforce's branch naming, it's
hard to go back to the
branch-name-is-suffix-on-version-number-of-each-file
way of life.)
Bitkeeper's doc is a bit thin on branches; for instance,
http://www.bitkeeper.com/manpages/bk-terms-1.html doesn't
have a definition for 'branch'.
So it seems that, unless one knows what one is doing,
one should avoid any revisions with more than one dot
in their name, and one should shun the tags 'v2.4.xx',
which are probably just mirrors of the Linus kernels.
Can someone confirm this, say a couple words on the use
of branches in the 2_4_devel tree, and explain how the
v2.4.xx tags are useful to linux ppc kernel hackers?
Thanks!
- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next reply other threads:[~2002-05-21 0:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-21 0:35 Dan Kegel [this message]
2002-05-21 1:00 ` bitkeeper, the 2_4_devel tree, and branches Dan Kegel
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=3CE99643.B7188518@ixiacom.com \
--to=dkegel@ixiacom.com \
--cc=dank@kegel.com \
--cc=linuxppc-embedded@lists.linuxppc.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).