----------------------------------------------------------------------
kernel mailing list version control tools discussion summary
----------------------------------------------------------------------
wishlist, list to judge scm tools:
- Ability to rename files/dirs
- Atomic patch set tagging (i.e. global tag patched files)
- Advanced merge conflict tool (i.e. tkdiff/gvimdiff like features)
- 2 way merge
- 3 way merge (like bk graphical 3-way merge)
- Remote branch repository support
- Multi-branch merging and tracking (i.e. merge once)
- per-file comments on checkins instead of a single per-checking
comment
- Storage of select inode metadata (i.e. link, pipe, dir, owner, ...)
- cvs dontcommit file.c (mark a private change)
----------------------------------------------------------------------
kernel mailing list version control tools discussion long summary
----------------------------------------------------------------------
Rik van Riel <riel@conectiva.com.br>
1) working merges
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.
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.
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)
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.
4) distributed repositories
I'm looking for the ability to make changes to my local tree while
away from the internet.
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.
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 ?
5) ability to exchange changesets by email
----------------------------------------------------------------------
Andrew Morton <akpm@zip.com.au>
> 1) working merges
Yes, cvs is poor at that. This is a bugfix, not a feature request :)
> 2) atomic checkins of entire patches, fast tags
Yes. changesets against a *group* of files (ie: a patch) needs
to become a first-class citizen.
> 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)
Current tkdiff is in fact very good at this. So integration
with that may suit.
The problem I find is that I often want to take (file1+patch) ->
file2,
when I don't have file1. But merge tools want to take (file1|file2)
-> file3.
I haven't seen a graphical tool which helps you to wiggle a patch
into
a file.
> 4) distributed repositories
>
> 5) ability to exchange changesets by email
These can probably be in version 2...
Probably the requirements of general developers differ from those
of tree-owners. The general developer is always working against
the official tree.
This is a bit extreme perhaps but I'm currently working code which
consists of twelve changesets against 100 files. Many of those
files are changed by multiple changesets. So two things:
1: If I have two changesets applied to a file, and I make a change to
that file, which changeset is it to be associated with?
2: The ability to move a set of changes from one changeset into
another one. ie: split that damn patch up!
But as a starting point I'd say: changesets as a first-class-concept,
and lots of integration with tkdiff.
----------------------------------------------------------------------Rik
van Riel <riel@conectiva.com.br>
Agreed, changesets, branches and merging are the first
priority.
----------------------------------------------------------------------Erik
Andersen <andersen@codepoet.org>
6) Ability to do sane archival and renaming of directories.
CVS doesn't even know what a directory is.
7) Support for archiving symlinks, device special files, fifos,
etc.
----------------------------------------------------------------------
Dave Jones <davej@suse.de>
> 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
minorish 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.
----------------------------------------------------------------------
Neil Brown <neilb@cse.unsw.edu.au>
>
> Current tkdiff is in fact very good at this. So integration
> with that may suit.
I find the e-diff mode in emacs quite good too. I had a quick look
at
tkdiff and it seems to be much the same sort of idea.
>
> The problem I find is that I often want to take (file1+patch) ->
file2,
> when I don't have file1. But merge tools want to take
(file1|file2) -> file3.
> I haven't seen a graphical tool which helps you to wiggle a patch
into
> a file.
If your saying what I think you're saying, I completely agree.
I often run "patch" and it drops some chunk because it doesn't match,
and it turns out that the miss-match is just one or two lines in a
chunk that could be very big.
I would like a tool (actually an emacs mode) that would show me
exactly
why a patch fails, and allow me to edit bits until it fits, and then
apply it. I assume that is what you mean by "wiggle a patch into a
file".
>
> This is a bit extreme perhaps but I'm currently working code which
> consists of twelve changesets against 100 files. Many of those
> files are changed by multiple changesets. So two things:
>
> 1: If I have two changesets applied to a file, and I make a change
to
> that file, which changeset is it to be associated with?
>
How about an editor which, when you view a file, gives you also a
little window onto that file for every other version in your current
series of change sets.
When you make a change it gets propagated forwards. To edit a
different changeset you just choose the right little window.
So many ideas... so little time....
NeilBrown
----------------------------------------------------------------------"H.
Peter Anvin" <hpa@zytor.com>
6) Real copy/rename support
----------------------------------------------------------------------
Alex Riesen <Alexander.Riesen@synopsys.com>
Try vimdiff/gvimdiff from VIM 6.0. I think it does pretty good that
job
(wiggle... what a word :)
-alex
----------------------------------------------------------------------
Pau Aliagas <linuxnow@wanadoo.es>
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
progress. http://www.regexps.com/
> > >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
branches...
> > >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.
> On Thu Mar 07, 2002 at 08:59:47PM -0300, Rik van Riel wrote:
> > 5) ability to exchange changesets by email
>
> 6) Ability to do sane archival and renaming of directories.
> CVS doesn't even know what a directory is.
Doable with arch. You can rename dirs and remove them, also files,
and it
will detect it generating a much smaller patchset. It all depends on
the
tagging you choose for files be it implicit -tags inside the file-,
explicit -ci, co- or by name.
> 7) Support for archiving symlinks, device special files, fifos,
> etc.
You chose what is source code with regular exps. Symlinks sure work,
the
rest not sure, but think so.
> If you could setup a public arch repository of the 2.4 / 2.5
> kernel of which everybody can copy/clone their arch kernel
> repository, that would be a good start.
It is not necessary to setup a central repository.
We need a reference archive to keep in sync with; then everybody
branches
from there and syncs back and forth. The reference archive would be
the
official kernel branch.
You could then have public archives to share your patchsets. And
access
other's archives who you are interested in staying in sync with.
> Even better would be an arch kernel repository that is kept
> up-to-date (automatically?) or gated from the bitkeeper tree.
We only need to update to the latest kernel to have the repository
updated, nothing else. You commit the patchset as "patch-2.5.6" and
that's
it. Then you grep you kernel25--rik and apply the changes from the
official branch automatically, reconciling differences. Once you want
to
"export" your changes to Linus, you export it in one or more
patchsets.
> That would give us some real way to compare the two tools.
It seems obvious that bitkeeper is in very good shape; I'm not at all
against people using, but I'm sure that if a few people tried arch,
they'd
be gratefully surprised. Testing and improvement is needed and very
welcome as well as kernel hackers aiming to try it.
----------------------------------------------------------------------
"Jonathan A. George" <JGeorge@greshamstorage.com>
1. Storage of select inode metadata (i.e. link, pipe, dir, owner,
...)
2. Ability to rename files
3. Atomic patch set tagging (i.e. global tag patched files)
4. Advanced merge conflict tool (i.e. tkdiff/gvimdiff like
features)
5. Remote branch repository support
6. Multi-branch merging and tracking (i.e. merge once)
The first three have been on my personal hit list for a while. A
good
implementation of 5 & 6 are probably the toughest to do properly, but
also seem like key elements for kernel developers due to the
importance
of multiple trees. I'm not really worried about the performance of
CVS
since any problems here can probably be solved by adding some
administrative meta data for caching and some tweaks to the back end.
However, it sounds as if Arch and PRCS are pretty interesting, and I
hope that a couple of people take a look at them to see how close it
is
to suitable. My respect for BK is certainly been enhanced by this
discussion, but I still would prefer a free (or failing that GPL)
license. ;-)
----------------------------------------------------------------------
Dave Jones <davej@suse.de>
Agreed. And I suggest anyone doing such a study investigate all
the different parts of bitkeeper, not just its file-management /
distributed repository features.
Little things make a lot of difference. Things like per-file
comments on checkins instead of a single per-checking comment.
And ease of use for some really mundane merge-tasks (See my earlier
mail in this thread for details)
----------------------------------------------------------------------
Kurt Roeckx <Q@ping.be>
> Could someone explain me, how this "merge once" works? How is this
> different from cvs? I mean, cvs is capable of doing merges, if new
> changes are not at the same position.
The way I currently work is I do a cvs diff, store it in a file,
and reverse apply it to my cvs tree, so I have a clean tree
again. You do this with several things you're working on.
Then someone changes something, so you do a cvs update, you apply
the patches, deal with conflicts if any, and make a new patch of it.
What I would like to see, and think that they mean is, I tag
those change as a "patch" in the tree, probably localy, and I
just do a cvs update, and if there are no conflicts, I'm done.
If you only have 1 thing you're working on (per tree), cvs update
should work, but I don't want to copy the tree several times.
----------------------------------------------------------------------
Pavel Machek <pavel@ucw.cz>
My pet feature?
cvs dontcommit file.c
What it should do? Mark changes in file.c as private to me, so that
it
never tries to commit them to official tree. It would be best if cvs
diff just pretended changes are not there.
So, if I checkout tree, do some dirty hacks to make it compile, do
cvs
dontcommit ., cvs diff should show nothing and cvs commit should try
to commit nothing. That would be nice,
----------------------------------------------------------------------
Larry McVoy <lm@bitmover.com>
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)
I haven't verified this, but I suspect what Rik is using is the 3-way
file merge. If it looks like
http://www.bitkeeper.com/newmerge.gif
that's a 3 way file merge, the 2 big side by side windows are showing
you 3 diffs, the diff from the ancestor to the local version in the
left
window, the diff from the ancestor to the remote version in the right
window, and then side by side diffs in that they are lined up.
If Rik is using the 2 way file merge and likes that, he's in for a
quantum
leap in productivity, commercial customers have reported as much as
an
18:1 productivity increase from the 3 way file merge.
And by the way, if you ever get around to understanding how this tool
works,
you'll then understand why I keep saying that BitKeeper !=
diff&patch. It
is impossible to do what this tool does with a diff&patch based
system, it
simply can't be done.
On Sat, Mar 09, 2002 at 02:22:33PM -0800, Tom Lord wrote:
> $ bk mv old new
>
> No danger, no drawbacks, no hand editing of history files.
>
> I like the arch way of renaming a file:
>
> $ mv old new
>
> (Yes, history is preserved, etc.)
Come on, Tom, truth in advertising. If you don't have the file
identifier
in the file, what you just described doesn't work.
Arch has a concept of an "inode" quite similar to BitKeeper, in fact
one wonders where the idea came from :-), and as long as the the
"inode"
is embedded in the file, you can do what Tom says above. If it
isn't,
that won't work, no matter what he says. I speak from the experience
of importing lots of kernel versions into BK and trying to automate
the
detection of renames. Can't be done and if Tom claims it can, then
ask him to demonstrate how by taking a a few thousand kernel patches
and autodetecting the renames.
----------------------------------------------------------------------
Rik van Riel <riel@conectiva.com.br>
> > > The problem I find is that I often want to take (file1+patch)
-> file2,
> > > when I don't have file1. But merge tools want to take
(file1|file2) -> file3.
> > > I haven't seen a graphical tool which helps you to wiggle a
patch into
> > > a file.
> > I often run "patch" and it drops some chunk because it doesn't
match,
> > and it turns out that the miss-match is just one or two lines in
a
> > chunk that could be very big.
> Yes, this would be [: very very :] nice.
Have you people heard about this thing called "branches" ?
- You keep your own code in your own branch.
- You keep Linus's code in a linus branch.
- The patches from Linus always apply to the linus branch.
- You pull Linus's latest updates into your own branch for
development work, at this point you may need to do some
merging. Some SCM systems are horrible at merging (CVS)
while others are really nice (BK).
No need to (badly) reinvent the wheel, all of this stuff has
been solved for many years now.
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 21 16:45:15 2002
