public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@suse.de>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "Jonathan A. George" <JGeorge@greshamstorage.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Kernel SCM: When does CVS fall down where it REALLY matters?
Date: Fri, 8 Mar 2002 02:19:09 +0100	[thread overview]
Message-ID: <20020308021909.L29587@suse.de> (raw)
In-Reply-To: <3C87FD12.8060800@greshamstorage.com> <Pine.LNX.4.44L.0203072057510.2181-100000@imladris.surriel.com>
In-Reply-To: <Pine.LNX.4.44L.0203072057510.2181-100000@imladris.surriel.com>; from riel@conectiva.com.br on Thu, Mar 07, 2002 at 08:59:47PM -0300

On Thu, Mar 07, 2002 at 08:59:47PM -0300, Rik van Riel wrote:

 > 3) graphical 2-way merging tool like bitkeeper has
 >    (this might not seem essential to people who have
 >    never used it, but it has saved me many many hours)

 For me, this is the 'killer feature' of bk, and is my sole reason
 for spending the last few days beating up Larry to make some minor-ish
 improvements.

 Say for example I want to push Linus reiserfs bits from my tree.

 Old method:
 - diff linux-vanilla linux-dj >dj.diff
 - grepdiff reiser dj.diff | xargs -n1 filterdiff dj.diff -i >reiser.diff
 - copy this file to reiser-1.diff reiser-2.diff with the intention
   of making each diff have only one 'theme'
 - vi reiser1.diff, chop out unneeded bits
 - repeat for all remaining files
 - check they all apply on top of Linus' latest.
 (If during any of the steps above, Linus puts out a new pre that
  touches any of the files these patches do, resync, and go back to step #1)

This, takes a long time. And for some of the more compilicated bits,
it's a pita to do.

The new method:
 - bk pull
 - bk citool
 - tag reiserfs files in cset
 - hide bits in this delta that don't apply to this csets 'theme' [1]
 - Once I have the grouped together cset, I generate a diff.
 If during any of these steps Linus changes any of these files, I
 bk pull, and with luck, bk does the nasty bits for me, and fires up
 the conflict resolution tool if needbe.

 The above steps look about equal in number, but in speed of operation
 for this work, bk wins hands down.
 
 I'm not aware of anything other than bk that has the functionality
 of citool and fmtool combined.  My usage pattern above doesn't fit
 the usual approach, as suggested in Jeff's minihowto, where I'd
 have multiple 'themed' trees for each cset I'd want to push Linus'
 way. With a 6MB diff, I'd need to grow a lot of themes, and fortunatly,
 bk can be quite easily bent into shape to fit my lazy needs.

 I'm going to be trying it out for the next round of merging with Linus
 (which is partly the reason I've not pushed anything his way recently)
 As soon as I'm done moving house this weekend, I'll be having quite a
 long play with bk, to see how much quicker and easier my life becomes.

 And the usual Larry disclaimer applies. I'll try it, and if it doesn't
 work out, I'll go back to my old way of working.
 
 Regards,
 Dave.

[1] This is what Larry has been working on for me the last few days
    For the most part, it's done, just needs some niggles working out.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

  parent reply	other threads:[~2002-03-08  1:19 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-07 23:51 Kernel SCM: When does CVS fall down where it REALLY matters? Jonathan A. George
2002-03-07 23:59 ` Rik van Riel
2002-03-08  0:03   ` Cort Dougan
2002-03-09 11:17     ` Roman Zippel
2002-03-09 16:45       ` Kurt Roeckx
2002-03-08  0:26   ` Andrew Morton
2002-03-08  0:36     ` Rik van Riel
2002-03-08  1:48     ` Neil Brown
2002-03-10 20:27       ` Pavel Machek
2002-03-11 21:11         ` Rik van Riel
2002-03-12 16:31           ` Pavel Machek
2002-03-08  7:37     ` Alex Riesen
2002-03-08  0:29   ` Jonathan A. George
2002-03-08  0:43     ` Rik van Riel
2002-03-08  9:32       ` Pau Aliagas
2002-03-08 16:37         ` Rik van Riel
2002-03-08 20:15           ` Pau Aliagas
2002-03-08 20:22             ` Rik van Riel
2002-03-08 20:28               ` Pau Aliagas
2002-03-08  0:38   ` Erik Andersen
2002-03-08  9:38     ` Pau Aliagas
2002-03-09  1:52     ` Val Henson
2002-03-09  2:00       ` Mike Fedyk
2002-03-09  2:25       ` Dave Jones
2002-03-08  1:19   ` Dave Jones [this message]
2002-03-08 20:27     ` Jonathan A. George
2002-03-08 21:59       ` Eli
2002-03-08  3:15   ` H. Peter Anvin
2002-03-08  9:39     ` Pau Aliagas
2002-03-11 17:05   ` Larry McVoy
2002-03-11 17:12     ` Randy.Dunlap
2002-03-11 17:25       ` Larry McVoy
2002-03-11 17:53       ` Jonathan A. George
2002-03-11 18:03         ` Larry McVoy
2002-03-11 20:36     ` Rik van Riel
2002-03-11 21:01       ` Larry McVoy
2002-03-11 21:28         ` Rik van Riel
2002-03-10 19:28 ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2002-03-09 22:22 Tom Lord
2002-03-11 17:10 ` Larry McVoy
2002-03-12  6:09   ` Tom Lord

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=20020308021909.L29587@suse.de \
    --to=davej@suse.de \
    --cc=JGeorge@greshamstorage.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    /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