I am considering adding some enhancements to CVS to address deficiencies
which adversely affect my productivity. Since it would obviously be
nice to have a completely free (or even GPL :-) tool which is not
considered to consist of unacceptable compromises in the process of
kernel development I would like to know what the Bitkeeper users
consider the minimum acceptable set of improvements that CVS would
require for broader acceptance. Obviously the tremendous set of
features that Bitkeeper has are nice, but I'd like to narrow the
comparative flaws to a manageable set.
Any comments would benefit all of the free SCM projects by at least
helping to provide a guiding light.
--Jonathan--
On Thu, 7 Mar 2002, Jonathan A. George wrote:
> I am considering adding some enhancements to CVS to address deficiencies
> which adversely affect my productivity.
> ... I would like to know what the Bitkeeper users consider the minimum
> acceptable set of improvements that CVS would require for broader
> acceptance.
1) working merges
2) atomic checkins of entire patches, fast tags
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)
4) distributed repositories
5) ability to exchange changesets by email
regards,
Rik
--
<insert bitkeeper endorsement here>
http://www.surriel.com/ http://distro.conectiva.com/
Only doing a given merge once is great. That's a big time-saver over the
long term.
} 1) working merges
}
} 2) atomic checkins of entire patches, fast tags
}
} 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)
}
} 4) distributed repositories
}
} 5) ability to exchange changesets by email
}
} regards,
}
} Rik
} --
} <insert bitkeeper endorsement here>
}
} http://www.surriel.com/ http://distro.conectiva.com/
}
} -
} To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
} the body of a message to [email protected]
} More majordomo info at http://vger.kernel.org/majordomo-info.html
} Please read the FAQ at http://www.tux.org/lkml/
Rik van Riel wrote:
>
> On Thu, 7 Mar 2002, Jonathan A. George wrote:
>
> > I am considering adding some enhancements to CVS to address deficiencies
> > which adversely affect my productivity.
>
> > ... I would like to know what the Bitkeeper users consider the minimum
> > acceptable set of improvements that CVS would require for broader
> > acceptance.
>
> 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 wrote:
>On Thu, 7 Mar 2002, Jonathan A. George wrote:
>
>>I am considering adding some enhancements to CVS to address deficiencies
>>which adversely affect my productivity.
>>
>
>>... I would like to know what the Bitkeeper users consider the minimum
>>acceptable set of improvements that CVS would require for broader
>>acceptance.
>>
>
>1) working merges
>
Can you be more specific?
>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?
>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?
>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?)
>5) ability to exchange changesets by email
>
That's a good one, and shouldn't be too bad if you like what I said for #2
>regards,
>
>Rik
>
--Jonathan--
On Thu, 7 Mar 2002, Andrew Morton wrote:
> Rik van Riel wrote:
> > On Thu, 7 Mar 2002, Jonathan A. George wrote:
> > 4) distributed repositories
> >
> > 5) ability to exchange changesets by email
>
> These can probably be in version 2...
Actually, I doubt Linus would let us use his repository,
aside from the scalability problems you get with 2000
people trying to use the same repository... ;)
> 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!
Could be solved with branches, but that's not too clean
either. Splitting up patches is a hard problem ...
> But as a starting point I'd say: changesets as a first-class-concept,
> and lots of integration with tkdiff.
Agreed, changesets, branches and merging are the first
priority.
regards,
Rik
--
<insert bitkeeper endorsement here>
http://www.surriel.com/ http://distro.conectiva.com/
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.
7) Support for archiving symlinks, device special files, fifos,
etc.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Thu, 7 Mar 2002, Jonathan A. George wrote:
> Rik van Riel wrote:
> >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.
> >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)
>
> 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.
> >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.
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 ?
regards,
Rik
--
<insert bitkeeper endorsement here>
http://www.surriel.com/ http://distro.conectiva.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)
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
On Thursday March 7, [email protected] wrote:
>
> 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
Followup to: <[email protected]>
By author: Rik van Riel <[email protected]>
In newsgroup: linux.dev.kernel
>
> 1) working merges
>
> 2) atomic checkins of entire patches, fast tags
>
> 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)
>
> 4) distributed repositories
>
> 5) ability to exchange changesets by email
>
6) Real copy/rename support
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Thu, Mar 07, 2002 at 04:26:41PM -0800, Andrew Morton wrote:
...
>
> 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.
>
Try vimdiff/gvimdiff from VIM 6.0. I think it does pretty good that job
(wiggle... what a word :)
-alex
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
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.
Pau
On 7 Mar 2002, H. Peter Anvin wrote:
> 6) Real copy/rename support
arch can do it too. Sorry to insist. If anyone preferes bk, it's ok for
me, use whatever gives you the best results, I'm not religious about that
issue. Competition is good.
Pau
On Thu, 7 Mar 2002, Erik Andersen wrote:
> 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.
Pau
On Fri, 8 Mar 2002, Pau Aliagas wrote:
> I'd recommend everybody to give arch a try.
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.
Even better would be an arch kernel repository that is kept
up-to-date (automatically?) or gated from the bitkeeper tree.
That would give us some real way to compare the two tools.
regards,
Rik
--
<insert bitkeeper endorsement here>
http://www.surriel.com/ http://distro.conectiva.com/
On Fri, 8 Mar 2002, Rik van Riel wrote:
> On Fri, 8 Mar 2002, Pau Aliagas wrote:
>
> > I'd recommend everybody to give arch a try.
>
> 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.
Pau
On Fri, 8 Mar 2002, Pau Aliagas wrote:
> On Fri, 8 Mar 2002, Rik van Riel wrote:
> > On Fri, 8 Mar 2002, Pau Aliagas wrote:
> >
> > > I'd recommend everybody to give arch a try.
> >
> > 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.
Exactly! Now, is there some arch fan willing to setup this
initial repository ?
> > 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.
Having an initial repository would get a lot of people
(including me, once I have a bit of time) to try out
arch.
regards,
Rik
--
<insert bitkeeper endorsement here>
http://www.surriel.com/ http://distro.conectiva.com/
Dave Jones wrote:
> 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)
>
>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.
>
This is a great example Dave, and is exactly the kind of feedback that
free SCM tool developers need. This is my current list of features CVS
doesn't have which are important for kernel developers (or me).
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. ;-)
Comments?
--Jonathan--
On Fri, 8 Mar 2002, Rik van Riel wrote:
> > We need a reference archive to keep in sync with; then everybody
> > branches from there and syncs back and forth.
>
> Exactly! Now, is there some arch fan willing to setup this
> initial repository ?
I'll do it.
> > > 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.
>
> Having an initial repository would get a lot of people
> (including me, once I have a bit of time) to try out
> arch.
We continue to discuss it in private and once it's ready and documented
let the list know.
Pau
Jonathan A. George wrote:
> My respect for BK is certainly been enhanced by this
> discussion, but I still would prefer a free (or failing that GPL)
> license. ;-)
>
> Comments?
A comment/request.
Take your list of requirements and see how each system "we" (as in
kernel hackers) use stacks up and post that to the list.
Be sure to include ARCH, Bitkeeper, CVS, diff&patch, emacs, SCCS,
Subversion, and any others I've missed... I don't know what all the
options are, and that is something that would be useful to know.
(Also, consider "bundles" such as CVS+cervisia+tkdiff or something).
The list should have comments about each rather than just a checklist,
so you give an idea of quality of implementations as well.
Actually, Larry McVoy might have such a compilation in his sales
materials, or should. ;)
Also, you didn't mention Subversion, which is a Free license, and has
many of the same stated goals as you have. There is some decent
documentation on their design and some discussion about _why_ they made
their choices. That should be worth-while reading regardless of the
path you choose to pursue. You might consider that if Subversion does
half of your goals it might be easier to add to it than start from CVS
or from scratch...
Comments?
Eli
disclaimer: I use CVS because it is what I know and it is available
"everywhere". I'm planning to use Subversion at some future date.
Plans subject to change based upon additional knowledge, partly from
this list. *shrug*
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
On Thu, Mar 07, 2002 at 05:38:27PM -0700, Erik Andersen wrote:
>
> 6) Ability to do sane archival and renaming of directories.
> CVS doesn't even know what a directory is.
How about sane renaming of plain old files?
For a laugh, read the instructions on how to "rename" CVS files.
Hint: "Rename" is not the correct word.
$ mv old new
$ cvs remove old
$ cvs add new
$ cvs commit -m "Renamed old to new" old new
Gee, that looks like adding a new file to me. Upon reading further,
that is exactly what this "rename" operation is doing. There are two
other ways to rename a file in CVS, one of which is described as
"dangerous" and the other as having "drawbacks." References:
http://www.gnu.org/manual/cvs-1.9/html_node/cvs_66.html
Note that the way to rename a file in in BitKeeper is:
$ bk mv old new
No danger, no drawbacks, no hand editing of history files.
I strongly recommend that anyone attempting to make CVS a viable
replacement for BitKeeper start out by actually using BitKeeper.
You're so used to being crippled by CVS that you don't even know what
you're missing.
-VAL
On Fri, Mar 08, 2002 at 06:52:38PM -0700, Val Henson wrote:
> On Thu, Mar 07, 2002 at 05:38:27PM -0700, Erik Andersen wrote:
> >
> > 6) Ability to do sane archival and renaming of directories.
> > CVS doesn't even know what a directory is.
>
> How about sane renaming of plain old files?
>
> For a laugh, read the instructions on how to "rename" CVS files.
> Hint: "Rename" is not the correct word.
>
> $ mv old new
> $ cvs remove old
> $ cvs add new
> $ cvs commit -m "Renamed old to new" old new
>
> Gee, that looks like adding a new file to me. Upon reading further,
> that is exactly what this "rename" operation is doing. There are two
> other ways to rename a file in CVS, one of which is described as
> "dangerous" and the other as having "drawbacks." References:
>
> http://www.gnu.org/manual/cvs-1.9/html_node/cvs_66.html
>
> Note that the way to rename a file in in BitKeeper is:
>
> $ bk mv old new
>
> No danger, no drawbacks, no hand editing of history files.
>
> I strongly recommend that anyone attempting to make CVS a viable
> replacement for BitKeeper start out by actually using BitKeeper.
> You're so used to being crippled by CVS that you don't even know what
> you're missing.
>
No.
They're not trying to make cvs fit into the space bk lives in now, they're
trying to take the cvs *replacements* (arch, subversion, etc) and make them
usable (they probably are close now, but not as good as bk) for kernel
development requirements.
On Fri, Mar 08, 2002 at 06:52:38PM -0700, Val Henson wrote:
> I strongly recommend that anyone attempting to make CVS a viable
> replacement for BitKeeper start out by actually using BitKeeper.
> You're so used to being crippled by CVS that you don't even know what
> you're missing.
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)
It's only through actual usage patterns that you'll see all the
neat time-saving gizmo's in there.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Val Henson:
For a laugh, read the instructions on how to "rename" CVS files.
Hint: "Rename" is not the correct word.
$ mv old new
$ cvs remove old
$ cvs add new
$ cvs commit -m "Renamed old to new" old new
[...] There are two other ways to rename a file in CVS, one of
which is described as "dangerous" and the other as having
"drawbacks." References:
Note that the way to rename a file in in BitKeeper is:
$ 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.)
-t
Hi,
Cort Dougan wrote:
> Only doing a given merge once is great. That's a big time-saver over the
> long term.
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.
bye, Roman
On Sat, Mar 09, 2002 at 12:17:07PM +0100, Roman Zippel wrote:
>
> Cort Dougan wrote:
>
> > Only doing a given merge once is great. That's a big time-saver over the
> > long term.
>
> 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.
Kurt
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.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, 11 Mar 2002, Larry McVoy wrote:
| 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.
Just curious, how is this productivity increase measured?
Thanks,
--
~Randy
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.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, Mar 11, 2002 at 09:12:31AM -0800, Randy.Dunlap wrote:
> On Mon, 11 Mar 2002, Larry McVoy wrote:
>
> | 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.
>
> Just curious, how is this productivity increase measured?
They redid the same really nasty merge with the old tools, with Sun's
file merge, and the new filemerge. It was a bit more than 18x faster
with the new file merge.
This same customer site, which hacks the kernel by the way, claims that
well over 90% of their BK usage is spent merging, so the productivity
gains in merging are translated almost 1:1 into wall clock gains.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Mon, 11 Mar 2002, Larry McVoy wrote:
>Arch has a concept of an "inode" quite similar to BitKeeper, in fact
>one wonders where the idea came from :-)
>
Oh please. I've used the concept of an "inode" for years when modeling
the information related to filesystem attributes simply because that is
what the filesystem itself uses, and when modeling something in a
filesystem the concept is self evident. I'm certain that every deep
version control system has a similar model (i.e. Clearcase which
explicitly is a filesystem)... It's not as if people are unaware of the
deficiencies of CVS and other free software version control systems,
they simply haven't yet invested the time to polish them because the
development cost failed the cost benefit analysis test for them.
I must give you credit for stirring things up and showing how great the
benefits are of a polished SCM system to the free software community.
However, between my computer science background and use of various
commercial SCM systems I see great polish and followthrough in
bitkeeper, but not much true originality. In other words your dig at
Tom was really out of line.
--Jonathan--
On Mon, Mar 11, 2002 at 11:53:38AM -0600, Jonathan A. George wrote:
> On Mon, 11 Mar 2002, Larry McVoy wrote:
>
> >Arch has a concept of an "inode" quite similar to BitKeeper, in fact
> >one wonders where the idea came from :-)
> >
> Oh please. I've used the concept of an "inode" for years when modeling
[yadda yadda]
Go look at an Arch inode. Then go look at a BK inode. I'm not talking
about the idea, I'm talking about the implementation.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Arch has a concept of an "inode" quite similar to BitKeeper, in
fact one wonders where the idea came from :-),
Common sense.
-t
Hi!
> I am considering adding some enhancements to CVS to address deficiencies
> which adversely affect my productivity. Since it would obviously be
> nice to have a completely free (or even GPL :-) tool which is not
> considered to consist of unacceptable compromises in the process of
> kernel development I would like to know what the Bitkeeper users
> consider the minimum acceptable set of improvements that CVS would
> require for broader acceptance. Obviously the tremendous set of
> features that Bitkeeper has are nice, but I'd like to narrow the
> comparative flaws to a manageable set.
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,
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
Hi!
> > 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".
Yes, this would be [: very very :] nice.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
On Mon, 11 Mar 2002, Larry McVoy wrote:
> 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
Actually, I've tried both the 3-way and the 2-way merge tools ...
> 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 I prefer the one which is chosen with 'f2', nothing beats
the [left] [right] buttons!
I guess maybe 10% of the time I need to edit something by hand,
but by far the most of the time I can just choose the code variant
on the left or on the right.
One mouse click is so much easier and faster than editing 5 lines
of code.
regards,
Rik
--
<insert bitkeeper endorsement here>
http://www.surriel.com/ http://distro.conectiva.com/
On Mon, Mar 11, 2002 at 05:36:23PM -0300, Rik van Riel wrote:
> ... and I prefer the one which is chosen with 'f2', nothing beats
> the [left] [right] buttons!
Hah. Try the bk-2.1.x series and try the 3way filemerge. The two way stuff
is nice, and I use it all the time for simple stuff, but when things get
nasty, the 3way filemerge is just amazingly good. You have to invest more
time to learn it because it is showing you more information, but our
customers have one by one moved over to it and would scream bloody murder
if we took it away, it's a huge timesaver.
The fact that you can get by with the 2way merge says that the merges you
are doing are easy. When they get harder, you'll need better tools. It's
cool that 2way works for you, but it's more cool that when it doesn't, we
already have the next level implemented.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sun, 10 Mar 2002, Pavel Machek wrote:
> > > 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.
regards,
Rik
--
<insert bitkeeper endorsement here>
http://www.surriel.com/ http://distro.conectiva.com/
On Mon, 11 Mar 2002, Larry McVoy wrote:
> On Mon, Mar 11, 2002 at 05:36:23PM -0300, Rik van Riel wrote:
> > ... and I prefer the one which is chosen with 'f2', nothing beats
> > the [left] [right] buttons!
> The fact that you can get by with the 2way merge says that the merges you
> are doing are easy. When they get harder, you'll need better tools.
Actually, it shows I know the VM code so well that I don't need to
see the common ancester to know what to merge. When I get into a
situation where I _don't_ know the code so well, I guess I'll want
the 3-way merge tool, like you said...
regards,
Rik
--
<insert bitkeeper endorsement here>
http://www.surriel.com/ http://distro.conectiva.com/
Hi!
> > > > 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).
Description above was basically how to do the merging. Oh, and for
people that have just one brach ("my own tree") patch should be quite
sufficient. Having patch more inteligent at rejects would be win for
everyone.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
