linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* bitkeeper, the 2_4_devel tree, and branches
@ 2002-05-21  0:35 Dan Kegel
  2002-05-21  1:00 ` Dan Kegel
  0 siblings, 1 reply; 2+ messages in thread
From: Dan Kegel @ 2002-05-21  0:35 UTC (permalink / raw)
  To: linuxppc-embedded@lists.linuxppc.org; +Cc: dank


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/

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: bitkeeper, the 2_4_devel tree, and branches
  2002-05-21  0:35 bitkeeper, the 2_4_devel tree, and branches Dan Kegel
@ 2002-05-21  1:00 ` Dan Kegel
  0 siblings, 0 replies; 2+ messages in thread
From: Dan Kegel @ 2002-05-21  1:00 UTC (permalink / raw)
  To: linuxppc-embedded@lists.linuxppc.org, dank


As a followup:

I saved
http://ppc.bkbits.net:8080/linuxppc_2_4_devel/ChangeSet@-1y?nav=index.html
as text in netscape, then ran it through
    grep -i ' 1\.[0-9]* .*Merge to 2.4'
to figure out which revisions with only one dot in
their changeset name roughly corresponded to Linus kernels.
Result:

  10 weeks  paulus      1.909    merge to 2.4.19-pre3 pulled from
linux_2_4 tree
  4 months  paulus      1.827    merge to 2.4.18-pre7
  5 months  paulus      1.796    merge to 2.4.18-pre2
  6 months  paulus      1.749    merge to 2.4.17-pre6
  7 months  paulus      1.654    merge to 2.4.15-pre5
  7 months  paulus      1.625    merge to 2.4.15-pre3
  7 months  trini       1.611    Merge to 2.4.15-pre1.
  9 months  paulus      1.468    merge to 2.4.10-pre11
  9 months  paulus      1.464    merge to 2.4.10-pre10
  9 months  paulus      1.456    merge to 2.4.10-pre9
  9 months  paulus      1.442    merge to 2.4.10-pre8
  9 months  paulus      1.440    new version of radeon driver, merge to
2.4.10-pre7
  9 months  paulus      1.439    merge to 2.4.10-pre7
  9 months  paulus      1.380    merge to 2.4.10-pre1
 10 months  paulus      1.294    merge to 2.4.9-pre1
 10 months  trini       1.257    Merge to 2.4.8-pre1
 11 months  paulus      1.209    merge to 2.4.7-pre5

This might be useful info for someone using the main branch
of linux_2_4 and who needs a bugfix that was introduced
with a particular Linus kernel, I suppose.
- Dan

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-05-21  1:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-05-21  0:35 bitkeeper, the 2_4_devel tree, and branches Dan Kegel
2002-05-21  1:00 ` Dan Kegel

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).