Problems using new Linux-2.4 bitkeeper repository.

Problems using new Linux-2.4 bitkeeper repository.

[James Bottomley]

How do those of us who've been using the

http://gkernel.bitkeeper.net/marcelo-2.4

for development resync against the kernel24.bkbits.net tree?  It looks like 
the changes from 2.4.18-pre8 onwards all have different patch IDs in the new 
tree; so when I try to do a pull from my current repository I get tons of 
conflicts, if I try to do a receive of just the patch set I get a resync error:

takepatch: can't find parent ID
        jgarzik@mandrakesoft.com|ChangeSet|20020225230300|18879
        in RESYNC/SCCS/s.ChangeSet

The thought of taking everything back to the common ancestor and then trying 
to apply the changes one at a time and adding the change logs by hand isn't 
that appealing (I have 3 2.4 repositories, some with upwards of 10 additional 
change sets in them).

James

Re: Problems using new Linux-2.4 bitkeeper repository.

[Jeff Garzik]

James Bottomley wrote:

>How do those of us who've been using the
>
>http://gkernel.bitkeeper.net/marcelo-2.4
>
>for development resync against the kernel24.bkbits.net tree?
>


Through the magic of BK :)

Just do a 'bk pull' on my marcelo-2.4 tree.  Since it is based on the 
original linux-2.4 tree just like Marcelo's tree, I was able to merge 
from my 2.4 line to his 2.4 line.

    Jeff

Re: Problems using new Linux-2.4 bitkeeper repository.

[James Bottomley]

jgarzik@mandrakesoft.com said:
> Through the magic of BK :)

> Just do a 'bk pull' on my marcelo-2.4 tree.  Since it is based on the
> original linux-2.4 tree just like Marcelo's tree, I was able to merge
> from my 2.4 line to his 2.4 line. 

Well, I tried this, but it just gave me a slew of initial rename conflicts.  
It could be something to do with the fact that my base development is still on 
2.4.18 (so the ancestors are easier to manage).

I finally solved it by writing a script to backport a bitkeeper change set to 
an earlier ancestor while preserving the change logs.  This is going to be 
helpful taking change sets between 2.4 and 2.5 anyway.

Thanks,

James

Re: Problems using new Linux-2.4 bitkeeper repository.

[Jeff Garzik]

James Bottomley wrote:

>jgarzik@mandrakesoft.com said:
>
>>Through the magic of BK :)
>>
>
>>Just do a 'bk pull' on my marcelo-2.4 tree.  Since it is based on the
>>original linux-2.4 tree just like Marcelo's tree, I was able to merge
>>from my 2.4 line to his 2.4 line. 
>>
>
>Well, I tried this, but it just gave me a slew of initial rename conflicts.  
>

This is normal, you just need to accept the remote changes for all those 
new/renamed files.  BitKeeper doesn't support doing this automatically 
for all files, so I had to highlight the expected BitKeeper response in 
another window, and then click <paste> on my mouse around 300 times... 
(~300 new files)

    Jeff

Re: Problems using new Linux-2.4 bitkeeper repository.

[Larry McVoy]

On Sat, Mar 16, 2002 at 11:28:46AM -0500, Jeff Garzik wrote:
> >Well, I tried this, but it just gave me a slew of initial rename conflicts.  
> >
> 
> This is normal, you just need to accept the remote changes for all those 
> new/renamed files.  BitKeeper doesn't support doing this automatically 
> for all files, so I had to highlight the expected BitKeeper response in 
> another window, and then click <paste> on my mouse around 300 times... 
> (~300 new files)

Yuck.  So you knew without any doubt what it was that you wanted?  How?
If this is a common case, I can add an option to the resolver, but it
strikes me that there must be some other problem here.  What are those
300 files?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Problems using new Linux-2.4 bitkeeper repository.

[Jeff Garzik]

Larry McVoy wrote:

>On Sat, Mar 16, 2002 at 11:28:46AM -0500, Jeff Garzik wrote:
>
>>>Well, I tried this, but it just gave me a slew of initial rename conflicts.  
>>>
>>This is normal, you just need to accept the remote changes for all those 
>>new/renamed files.  BitKeeper doesn't support doing this automatically 
>>for all files, so I had to highlight the expected BitKeeper response in 
>>another window, and then click <paste> on my mouse around 300 times... 
>>(~300 new files)
>>
>
>Yuck.  So you knew without any doubt what it was that you wanted?  How?
>If this is a common case, I can add an option to the resolver, but it
>strikes me that there must be some other problem here.  What are those
>300 files?
>

I started with Linus's linux-2.4 repo and so did Marcelo.  We 
independently checked in 2.4.recent patches (including proper renametool 
use), which included the ia64 and mips merges, which added a ton of 
files.  When you do a 'bk pull' from Marcelo's linux-2.4 into my old 
marcelo-2.4 repo, you have to individually tell BitKeeper that you 
really do want to trust Marcelo's copy over my own, for each of the ~300 
new files that were added between Linus's linux-2.4 repo creation and 2 
days ago.  So I highlighted "rl\ny\n" in another window, and wore out my 
middle mouse button...  Renames could have been handled similarly, but 
there were few renames, so I just typed "r\ny\n" manually maybe 10 or 20 
times.

One could argue that a "rla" or "lla" command would be useful when 
resolving a conflict between two new files, telling BitKeeper to accept 
remote (or local) additions in this case _and_ all succeeding cases.

One could also argue that BitKeeper needs to be twacked on the head 
because it is not detecting that the file-creates and file-renames are 
100% the same, content-wise.

    Jeff

Re: Problems using new Linux-2.4 bitkeeper repository.

[Larry McVoy]

On Sat, Mar 16, 2002 at 11:41:27AM -0500, Jeff Garzik wrote:
> I started with Linus's linux-2.4 repo and so did Marcelo.  We 
> independently checked in 2.4.recent patches (including proper renametool 
> use), which included the ia64 and mips merges, which added a ton of 
> files.  

OK, so there is the root cause.  It's time to talk about duplicate changes.
You know how Linus hates bad csets in the history and doesn't want them
there?  Well, I hate duplicate csets and don't want them there.  There are
lots of reasons.  One reason is that it means revtool is a lot less useful
for debugging.  If you are trying to track down the change which caused a
bug but it is obscured by a duplicate patch, you just got hosed.  Another
reason is file creates.  Suppose you and Marcelo both created a file called
"foo".  You pull, there is a file conflict, you remove one of the two files.
It isn't actually removed, it's just moved to BitKeeper/deleted.  Time passes
and you or someone else is fixing bugs in a pre-merged copy of the tree and
you are updating "foo".  You later pull that bugfix into the merged tree
and the bugfix happily is applied to the *deleted* copy of the file, since
the changes follow the "inode", not the pathname.  Bummer, you are now
scratching your head wondering where your bugfix went.

There are things we can do in BK to deal with this, but they are not easy
and are going to take several months, is my guess.  I'd like to see if you
can work around this by avoiding duplicate patches.  If you can, do so, 
you will save yourself lots of grief.

If you get into a duplicate patch situation, you are far better off to 
pick one tree or the other tree as the official tree, and cherrypick
the changes that the unofficial tree has and place them in the official
tree.  Then toss the unofficial tree.  I can make you a "bk portpatch"
command which does this, we have that already, it needs a bit of updating
to catch the comments.

You really want to listen to this, I'm trying to head you off from screwing
up the history.  If you get 300 renames like this, it's almost always a 
duplicate patch scenario.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Problems using new Linux-2.4 bitkeeper repository.

[Jeff Garzik]

Larry McVoy wrote:

>On Sat, Mar 16, 2002 at 11:41:27AM -0500, Jeff Garzik wrote:
>
>>I started with Linus's linux-2.4 repo and so did Marcelo.  We 
>>independently checked in 2.4.recent patches (including proper renametool 
>>use), which included the ia64 and mips merges, which added a ton of 
>>files.  
>>
>
>OK, so there is the root cause.  It's time to talk about duplicate changes.
>
[...]

>There are things we can do in BK to deal with this, but they are not easy
>and are going to take several months, is my guess.  I'd like to see if you
>can work around this by avoiding duplicate patches.  If you can, do so, 
>you will save yourself lots of grief.
>
[...]

>You really want to listen to this, I'm trying to head you off from screwing
>up the history.  If you get 300 renames like this, it's almost always a 
>duplicate patch scenario.
>

I know why it happened, silly.

This was just an example of a real world example that actually happened, 
where BK sucked ass :)

Marcelo's BK tree did not exist when I created my marcelo-2.4 tree. 
 marcelo-2.4 repo existed for a while and people started using it.  Once 
Marcelo appeared with his "official" BK tree, people naturally want to 
migrate.  There were two migration paths: (1) export everything to GNU 
patches, or (2) click the mouse 300 times.

So, knowing that duplicate patches are a bad thing helps not in the 
least here...

    Jeff

Re: Problems using new Linux-2.4 bitkeeper repository.

[Larry McVoy]

On Sat, Mar 16, 2002 at 12:06:10PM -0500, Jeff Garzik wrote:
> This was just an example of a real world example that actually happened, 
> where BK sucked ass :)

Think file systems.  Think 2 file systems.  Think creating duplicate inodes
in the same place.  Now those 2 file systems are merged into a third, the
duplicates removed.  The original 2 still both exist and are both being
updated.  

> Marcelo's BK tree did not exist when I created my marcelo-2.4 tree. 
>  marcelo-2.4 repo existed for a while and people started using it.  Once 
> Marcelo appeared with his "official" BK tree, people naturally want to 
> migrate.  There were two migration paths: (1) export everything to GNU 
> patches, or (2) click the mouse 300 times.

There is a 3rd:  factor out the duplicates and and export/import only the
ones that Marcelo didn't have, then dump your tree and use his.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Problems using new Linux-2.4 bitkeeper repository.

[James Bottomley]

lm@bitmover.com said:
> If you get into a duplicate patch situation, you are far better off to
>  pick one tree or the other tree as the official tree, and cherrypick
> the changes that the unofficial tree has and place them in the
> official tree.  Then toss the unofficial tree.  I can make you a "bk
> portpatch" command which does this, we have that already, it needs a
> bit of updating to catch the comments. 

That's essentially what I had to write to move my trees over, so an official 
one would be extremely useful.  I do have the piece which catches the comments 
if you want it.

jgarzik@mandrakesoft.com said:
> So, knowing that duplicate patches are a bad thing helps not in the
> least here... 

If bitkeeper had a way of replacing duplicate patches, this would be extremely 
useful.  All I really needed to do was replace the keys in the changelog from 
the garzik tree with the mareclo one to get my changes moved over.  I think 
essentially this could be done with a bk send|bk receive as long as I can tell 
bitkeeper that it needs a substitute set of keys when applying the bkpatch.

James

Re: Problems using new Linux-2.4 bitkeeper repository.

[Jeff Garzik]

Larry McVoy wrote:

>On Sat, Mar 16, 2002 at 12:06:10PM -0500, Jeff Garzik wrote:
>
>>This was just an example of a real world example that actually happened, 
>>where BK sucked ass :)
>>
>
>Think file systems.  Think 2 file systems.  Think creating duplicate inodes
>in the same place.  Now those 2 file systems are merged into a third, the
>duplicates removed.  The original 2 still both exist and are both being
>updated.  
>
Like I said, I know why BK is going what it is doing.  That doesn't 
change the fact that peoples options are very poor in this case.

>>Marcelo's BK tree did not exist when I created my marcelo-2.4 tree. 
>> marcelo-2.4 repo existed for a while and people started using it.  Once 
>>Marcelo appeared with his "official" BK tree, people naturally want to 
>>migrate.  There were two migration paths: (1) export everything to GNU 
>>patches, or (2) click the mouse 300 times.
>>
>
>There is a 3rd:  factor out the duplicates and and export/import only the
>ones that Marcelo didn't have, then dump your tree and use his.
>

That's what I meant by option #1...  you yelled at me, rightly, when I 
first tried to send BK patches to Linus, because I used 'bk export'.  If 
you have to leave the BK system entirely for certain cases of merging, 
that's really a failing of the system.  So, I chastise you back for even 
suggesting 'export' :)

Basically you need out of order changes to do it right...

I think a fair question would be, is this scenario going to occur often? 
 I don't know.  But I'll bet you -will- see it come up again in kernel 
development.  Why?  We are exercising the distributed nature of the 
BitKeeper system.  The system currently punishes Joe in Alaska and 
Mikhail in Russia if they independently apply the same GNU patch, and 
then later on wind up attempting to converge trees.

Do you see what I'm getting at?  In a widely distributed SCM system for 
an open source project, chances are -good- that some random two or more 
people will independently apply the same patch.

    Jeff

Re: Problems using new Linux-2.4 bitkeeper repository.

[Larry McVoy]

> I think a fair question would be, is this scenario going to occur often? 
>  I don't know.  But I'll bet you -will- see it come up again in kernel 
> development.  Why?  We are exercising the distributed nature of the 
> BitKeeper system.  The system currently punishes Joe in Alaska and 
> Mikhail in Russia if they independently apply the same GNU patch, and 
> then later on wind up attempting to converge trees.

Indeed.  So speak in file systems, because a BK package is basically a file
system, with multiple distributed instances, all of which may be out of
sync.  The problems show up when the same patch is applied N times and 
then comes together.  The inodes collide.  Right now, you think that's
the problem, and want BK to fix it.  We can fix that.  But that's not 
the real problem.  The real problem is N sets of diffs being applied
and then merged.  The revision history ends up with the data inserted N
times.

I'm not sure what to do about it.  I can handle the duplicate inode case
more gracefully but it's a heavy duty rewack.

We could play games where we detect the same patch inserted multiple times
and refuse to merge them.  Hmm. Hmm.  Not sure that helps.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Problems using new Linux-2.4 bitkeeper repository.

[Jeff Garzik]

Larry McVoy wrote:

>>I think a fair question would be, is this scenario going to occur often? 
>> I don't know.  But I'll bet you -will- see it come up again in kernel 
>>development.  Why?  We are exercising the distributed nature of the 
>>BitKeeper system.  The system currently punishes Joe in Alaska and 
>>Mikhail in Russia if they independently apply the same GNU patch, and 
>>then later on wind up attempting to converge trees.
>>
>
>Indeed.  So speak in file systems, because a BK package is basically a file
>system, with multiple distributed instances, all of which may be out of
>sync.  The problems show up when the same patch is applied N times and 
>then comes together.  The inodes collide.  Right now, you think that's
>the problem, and want BK to fix it.  We can fix that.  But that's not 
>the real problem.  The real problem is N sets of diffs being applied
>and then merged.  The revision history ends up with the data inserted N
>times.
>
>I'm not sure what to do about it.  I can handle the duplicate inode case
>more gracefully but it's a heavy duty rewack.
>

Hence my suggestion for a short term solution that's immediately useful 
-- allowing some way to answer "local changes take precedence 100% of 
the time" or "remote changes ..." with a single command.  That was my 
hack solution that I thought would people might find useful when stuck 
with the duplicate-patch situation.

In the command line merge tool, when merging a file-create, "rla" would 
cause the current file conflict, and all future file-create conflicts, 
to be "won" by the remote side -- essentially creating the effect of 
typing "rl" 300 times.
Apply similar logic to the file-rename merge case.  I think the merge 
command I used in 100% of the cases, during that merge, was 'r'.

If you are stuck with the duplicate patch case, as happened here, I just 
want to see the pain eased a bit :)  IMO you can put off the hard 
problem if you make the UI a bit better.

    Jeff

Re: Problems using new Linux-2.4 bitkeeper repository.

[Jeff Garzik]

Larry McVoy wrote:

>>I think a fair question would be, is this scenario going to occur often? 
>> I don't know.  But I'll bet you -will- see it come up again in kernel 
>>development.  Why?  We are exercising the distributed nature of the 
>>BitKeeper system.  The system currently punishes Joe in Alaska and 
>>Mikhail in Russia if they independently apply the same GNU patch, and 
>>then later on wind up attempting to converge trees.
>>
>
>Indeed.  So speak in file systems, because a BK package is basically a file
>system, with multiple distributed instances, all of which may be out of
>sync.  The problems show up when the same patch is applied N times and 
>then comes together.  The inodes collide.  Right now, you think that's
>the problem, and want BK to fix it.  We can fix that.  But that's not 
>the real problem.  The real problem is N sets of diffs being applied
>and then merged.  The revision history ends up with the data inserted N
>times.
>

Another thought, that I'm betting you laugh at me for even suggesting :)

Don't insert the data N times.  Give the user the option to say that one 
or more changesets are actually the same one.  In filesystem speak, 
unlink a file B which is a user-confirmed duplicate of file A, and 
re-create file B as a symlink to file A.  Or just unlink file B without 
the symlink, whichever metaphor suits you better.  :)

Yes it is "altering history"... but... OTOH the user has just told 
BitKeeper, in no uncertain terms, that he is altering history only to 
make it more correct.

 From a user interface perspective, the user would pick one of N 
changeset comments to be considered the "real" one.

    Jeff

Re: Problems using new Linux-2.4 bitkeeper repository.

[Christer Weinigel]

Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
> Hence my suggestion for a short term solution that's immediately useful 
> -- allowing some way to answer "local changes take precedence 100% of 
> the time" or "remote changes ..." with a single command.  That was my 
> hack solution that I thought would people might find useful when stuck 
> with the duplicate-patch situation.
> 
> In the command line merge tool, when merging a file-create, "rla" would 
> cause the current file conflict, and all future file-create conflicts, 
> to be "won" by the remote side -- essentially creating the effect of 
> typing "rl" 300 times.
> Apply similar logic to the file-rename merge case.  I think the merge 
> command I used in 100% of the cases, during that merge, was 'r'.

One variant of this would be to automatically use the remote file as
long as the file contents are the same.  That way, if I apply a patch
locally and Marcello/Linus later apply the same patch and put it into
the official tree, I can use the official version.  This would
probably handle most of the conflicts I have seen so far.  If there
are any "real" conflicts, I can handle them manually.  

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Re: Problems using new Linux-2.4 bitkeeper repository.

[Larry McVoy]

On Sat, Mar 16, 2002 at 01:05:26PM -0500, Jeff Garzik wrote:
> Larry McVoy wrote:
> 
> >>I think a fair question would be, is this scenario going to occur often? 
> >> I don't know.  But I'll bet you -will- see it come up again in kernel 
> >>development.  Why?  We are exercising the distributed nature of the 
> >>BitKeeper system.  The system currently punishes Joe in Alaska and 
> >>Mikhail in Russia if they independently apply the same GNU patch, and 
> >>then later on wind up attempting to converge trees.
> >>
> >
> >Indeed.  So speak in file systems, because a BK package is basically a file
> >system, with multiple distributed instances, all of which may be out of
> >sync.  The problems show up when the same patch is applied N times and 
> >then comes together.  The inodes collide.  Right now, you think that's
> >the problem, and want BK to fix it.  We can fix that.  But that's not 
> >the real problem.  The real problem is N sets of diffs being applied
> >and then merged.  The revision history ends up with the data inserted N
> >times.
> >
> 
> Another thought, that I'm betting you laugh at me for even suggesting :)
> 
> Don't insert the data N times.  Give the user the option to say that one 
> or more changesets are actually the same one.  In filesystem speak, 
> unlink a file B which is a user-confirmed duplicate of file A, and 
> re-create file B as a symlink to file A.  Or just unlink file B without 
> the symlink, whichever metaphor suits you better.  :)
> 
> Yes it is "altering history"... but... OTOH the user has just told 
> BitKeeper, in no uncertain terms, that he is altering history only to 
> make it more correct.

You need to put on the distributed-think hat.  The problem is never
what I do in any one instance, we can do all sorts of useful things
in that instance.  The problem is doing them in such a way so that
synchronization with repositories which are both ahead and behind works.
So if you repull from whereever you just pulled from, the system needs
to remember that some cset is a duplicate and has been eliminated.
And if you pull in the opposite direction, the past events, including
duplicate removal, propagate.

*All* of this stuff is trivial if you don't care about passing it on, if
your repository is a backwater dead end.  But that's not the case.
So you have to decide that you want the events to propagate and if you
do, then we can do something about it.

I'm starting to get psyched about this, I think I see a picture that 
works, I need to chew on it for a bit though.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Problems using new Linux-2.4 bitkeeper repository.

[Jeff Garzik]

Larry McVoy wrote:

>>Yes it is "altering history"... but... OTOH the user has just told 
>>BitKeeper, in no uncertain terms, that he is altering history only to 
>>make it more correct.
>>

>*All* of this stuff is trivial if you don't care about passing it on, if
>your repository is a backwater dead end.  But that's not the case.
>So you have to decide that you want the events to propagate and if you
>do, then we can do something about it.
>

Re-read my message, assuming I have a clue :)  This fits just fine into 
the distribute BK system, across any number of pushes and pulls.

I -would- want to pass on the fact that I merged multiple changesets 
into a single one...

Think about this example:
* I merge a GNU patch into tree A, creating cset 1.111.
* Marcelo merges the same GNU patch into tree B, creating cset 1.222.
* Time passes.  People clone repos off of both trees.
* I 'bk pull' from tree B.  Through the merge process, this creates a 
brand new "symlink cset", 1.333, which propagates the notion that my 
cset 1.111 is a complete copy of 1.222, so we should just read the data 
and revision history from 1.222.
* Now, I 'bk push' some changes to Marcelo.  This pushes, among other 
things, the magic symlink cset 1.333.  It does not push 1.111, since 
1.333 was the change to the local repo that told it not to.  Think of 
this like "cset -x" except smarter.  "cset -x", as I understand it, 
creates a new cset which is essentially the reverse of the specified 
cset.  Our symlink cset says to BitKeeper (a) not bother with 
patch-and-unpatch if both 1.111 and 1.222 are found to be missing 
downstream, and (b) if 1.111 but 1.222 are present downstream, to remove 
the data associated with 1.111, turning it into a symlink to 1.222.

This fits perfectly well into the BK distributed system, and works 
across any number of bk pushes and pulls.  Basically, "symlink csets" 
would show up in 'bk changes', much like merge csets show up in 'bk 
changes' now.

And you are no longer inserting the data N times.  The symlink csets 
take care of that.

And further, for people scattered all over the world with 1.111 cset, 
the 1.333 cset will slowly worm its way across the world, acting like a 
janitor and cleaning up BK repositories with duplicated patches :) 
 Isn't that neat? :)
(assuming that 1.333 cset is propagated out to the world, of course)

>I'm starting to get psyched about this, I think I see a picture that 
>works, I need to chew on it for a bit though.
>

whichever works :)

    Jeff, who really should sleep now :)

Re: Problems using new Linux-2.4 bitkeeper repository.

[David Woodhouse]

jgarzik@mandrakesoft.com said:
>  The system currently punishes Joe in Alaska and  Mikhail in Russia if
> they independently apply the same GNU patch, and  then later on wind
> up attempting to converge trees.

I tried to work round this by applying some patches which I require but 
which Linus hasn't yet taken _only_ in my working tree, not actually 
committing them. 

But then BK wouldn't even let me pull from Linus' tree any more, because I 
had locked and modified files. That also seems to be a fundamental flaw.


--
dwmw2

Re: Problems using new Linux-2.4 bitkeeper repository.

[Larry McVoy]

On Sun, Mar 17, 2002 at 10:49:34AM +0000, David Woodhouse wrote:
> But then BK wouldn't even let me pull from Linus' tree any more, because I 
> had locked and modified files. That also seems to be a fundamental flaw.

BK works that way on purpose.  If we merge changes into your local changes,
there is no automatic way to "unmerge".  It is way to easy to do a pull,
do the merge, and then realize you lost work in the merge because you told
it to do the wrong thing.

Short summary: commit your changes before you pull and you'll be fine.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Problems using new Linux-2.4 bitkeeper repository.

[David Woodhouse]

lm@bitmover.com said:
>  BK works that way on purpose.  If we merge changes into your local
> changes, there is no automatic way to "unmerge".  It is way to easy to
> do a pull, do the merge, and then realize you lost work in the merge
> because you told it to do the wrong thing.

> Short summary: commit your changes before you pull and you'll be fine.

If it was changes that deserved a changelog, I'd have committed them. But 
it's typically one-line hacks to make it compile, which I know will be 
obsoleted by 'correct' fixes in Linus' tree later. I don't want them (and 
the subsequent merges and conflicting new files) cluttering up my tree, 
especially as AFAICT BK won't let me undo the change later if I commit any 
changes after it - even if the later changes are _completely_ unrelated.

Btw, the citool is cute but would be cuter if
 - the diffs were '-up' format - showing the function that the hunk is in.
 - You could select a hunk and say "omit this change from what's committed"

Again, the latter is because some stuff really does live as local hacks in 
a build tree and never deserves the honour of a changelog entry.

Another thing I have a distinct feeling I'm going to want is tracking
functions across files. I sometimes shuffle functions between files for
portability - selective compilation is nicer with your Linux-specific
functions in one file and eCos-specific functions in another than with a
litter of ifdefs. If Linus' tree gets a patch to a file that I moved, BK can
work it out. If Linus' tree gets a patch to a _function_ that I moved to a
different file while leaving the rest of the original file in place, AFAICT
not even the merge tool deals with that nicely. Did I miss an option to
'apply this diff hunk to a different file'?


--
dwmw2

Re: Problems using new Linux-2.4 bitkeeper repository.

[Larry McVoy]

On Sun, Mar 17, 2002 at 04:23:21PM +0000, David Woodhouse wrote:
> 
> lm@bitmover.com said:
> >  BK works that way on purpose.  If we merge changes into your local
> > changes, there is no automatic way to "unmerge".  It is way to easy to
> > do a pull, do the merge, and then realize you lost work in the merge
> > because you told it to do the wrong thing.
> 
> > Short summary: commit your changes before you pull and you'll be fine.
> 
> If it was changes that deserved a changelog, I'd have committed them. But 
> it's typically one-line hacks to make it compile, which I know will be 
> obsoleted by 'correct' fixes in Linus' tree later. 

Then you get to save them as diffs, unedit the files, and put them back 
after the merge.

> Btw, the citool is cute but would be cuter if
>  - the diffs were '-up' format - showing the function that the hunk is in.

citool is a tcl program, how about you hack it in?  Look for $diffsOpts,
that's what you'll need to modify.  You need to get the diffs parsing 
code to do the right thing with -up style diffs though.

>  - You could select a hunk and say "omit this change from what's committed"

Get bk-2.1.5.  We added multiple options to the edit button, try the fmtool
option and learn how to use it.  You can trivially walk the code and pick
and choose which diffs you want.

> Another thing I have a distinct feeling I'm going to want is tracking
> functions across files. I sometimes shuffle functions between files for
> portability - selective compilation is nicer with your Linux-specific
> functions in one file and eCos-specific functions in another than with a
> litter of ifdefs. If Linus' tree gets a patch to a file that I moved, BK can
> work it out. If Linus' tree gets a patch to a _function_ that I moved to a
> different file while leaving the rest of the original file in place, AFAICT
> not even the merge tool deals with that nicely. Did I miss an option to
> 'apply this diff hunk to a different file'?

We don't have this feature.  We've talked about it, but that's all we've
done.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

Re: Problems using new Linux-2.4 bitkeeper repository.

[David Woodhouse]

lm@bitmover.com said:
>  Then you get to save them as diffs, unedit the files, and put them
> back  after the merge. 

I can do better than that. If I save them as diffs, I don't get to use your 
cute merge tools. I could commit them with a throwaway changelog, do the 
pull and use the merge tools, then copy the resulting files, undo both the 
pull and the previous merge, do the pull again and then lock the files and 
drop the previously-saved copies into place.

It's a bit contrived though - it would be nice if BK would do something 
like that for me instead of just bailing out when files are modified. 
Asking me if I'm really sure I want to continue is fine. Aborting 
unconditionally less so.

>  citool is a tcl program, how about you hack it in?  Look for
> $diffsOpts, that's what you'll need to modify.  You need to get the
> diffs parsing  code to do the right thing with -up style diffs though.

Er, actually I can't get 'bk diffs -up' to give output the same as (GNU)
'diff -up' either. What I was after was stuff like:

	@@ -331,6 +331,7 @@ int jffs2_decompress(unsigned char compr

> We don't have this feature.  We've talked about it, but that's all
> we've done.

Which? Actually tracking functions that move between files, or the hack in
the merge tool? I appreciate that the former is a _lot_ harder to achieve.

--
dwmw2

Re: Problems using new Linux-2.4 bitkeeper repository.

[Tom Rini]

On Sun, Mar 17, 2002 at 06:34:29PM +0000, David Woodhouse wrote:
> 
> lm@bitmover.com said:
> >  Then you get to save them as diffs, unedit the files, and put them
> > back  after the merge. 
> 
> I can do better than that. If I save them as diffs, I don't get to use your 
> cute merge tools. I could commit them with a throwaway changelog, do the 
> pull and use the merge tools, then copy the resulting files, undo both the 
> pull and the previous merge, do the pull again and then lock the files and 
> drop the previously-saved copies into place.

Well, what we're doing in PPC-land is we've got one tree, 'linuxppc-2.5'
which is linux-2.5 + for-linus-ppc* trees + hacks/fixes for current
problems.  So when we do any work you make a clone of a linux-2.5 tree
to work in, a clone of the linuxppc-2.5 tree (to pull your work tree
into and then test).  Once things are good in the linux-2.5-work tree,
you pull that into a for-linus tree and tell linus to merge that. 

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/