[lkml]   [2002]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Kernel SCM: When does CVS fall down where it REALLY matters?
On Thu, 7 Mar 2002, Rik van Riel wrote:

> On Thu, 7 Mar 2002, Jonathan A. George wrote:
> > Rik van Riel wrote:

I'd recommend everybody to give arch a try. It's still in an early
development stage but functional. More testing is needed to make it

> > >1) working merges
> >
> > Can you be more specific?
> You do a merge of a particular piece of code once.
> After that the SCM remembers that this merge was done
> already and doesn't ask me to do it again when I move
> my code base to the next official kernel version.

You can do that, can have separate branches, distributed repository, any
normal development tree can be an arch. You have reconcile among
distributed versions, star-merge, patches replay or update in any
direction. You choose what you want to merge, you can always list the
missing patches, you can generate the needed patches to join the

> > >2) atomic checkins of entire patches, fast tags
> >
> > I was thinking about something like automatically tagged globally
> > descrete patch sets. It would then be fairly simple to create a tool
> > that simply scanned, merged, and checked in that patch as a set. Is
> > something like this what you have in mind?
> Yes, but doing this with the CVS storage as back-end
> would just be too slow. Also, the CVS model wouldn't
> be able to easily clean out the tree afterwards if a
> checkin is interrupted halfway through.

Patchsets are available too.

> > >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)
> >
> > Would having something like VIM or Emacs display a patch diff with
> > providing keystroke level merge and unmerge get toward helpful for
> > something like this, or is the need too complex to address that way?
> That would work, but you really need to try bitkeeper's
> graphical 2-way merge tool (or even a screenshot) to see
> how powerful such a simple thing can (and should) be.

No fancy graphical tools, but great text tools by now.

> > >4) distributed repositories
> >
> > Can you be more specific? (i.e. are you looking for merging,
> > syncronization, or copies? In other words what do you need that CVS +
> > rsync are unacceptable for?)
> I'm looking for the ability to make changes to my local tree while
> away from the internet.

Doable, BTW it's the normal way of working in arch.

> I want to be able to make a branch for some new VM stuff while I'm
> sitting on an airplane, without needing to "register" the branch
> with the SCM daemon on Linus's personal workstation.

That's what you are expected to do, you work in your code derived from a
concret point in the, let's call, reference repository.
You can always see the differences, move them from one branch to the
other, make the mavailable to others to "get"... No need to register
anything, only to get a remote public archive you need to specify the
location and version that you want to download.

> Another thing to consider here is that you'll have dozens, if not
> hundreds, of people creating branches to their tree simultaneously.
> How would you ever convince rsync to merge those ?

You can't. But you can pull from the branches you need the patchsets you
choose to. And make your branches public and available for others. It's
very easy if you understand what's your development branch and your
private branch. You move patches back and forth automatically. Even
patches coming from the original trunk.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.074 / U:14.952 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site