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
[email protected]|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
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
[email protected] 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
James Bottomley wrote:
>[email protected] 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
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
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
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
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
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
[email protected] 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.
[email protected] 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
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
> 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
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
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
Jeff Garzik <[email protected]> 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?"
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
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 :)
[email protected] 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
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
[email protected] 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
On Sun, Mar 17, 2002 at 04:23:21PM +0000, David Woodhouse wrote:
>
> [email protected] 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
[email protected] 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
On Sun, Mar 17, 2002 at 06:34:29PM +0000, David Woodhouse wrote:
>
> [email protected] 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/