<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> John Arbash Meinel wrote: <blockquote cite="mid:498C3C3E.4020003@arbash-meinel.com" type="cite"> <pre wrap="">-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kent Gibson wrote: </pre> <blockquote type="cite"> <pre wrap="">I also had problems applying the patch to bzr.dev (r3984) - I got the same result as Colin. Either something is broken in your patch, or in bzr itself (1.11). So I pulled a copy of the partial-delta branch and merged your patch into that so I could have a play with it. That appeared to work. e.g. ./bzr log tools does not crash. Can't comment on it's correctness (yet), but at least it didn't crash. </pre> </blockquote> <pre wrap=""> I'm pretty sure it isn't either, but an actual intentional effect of how Ian generated the merge directive. I would guess that Ian supplied an explicit range when he generated the bundle ("bzr send -r X..Y"). As such when someone applies that change, it will perform an implicit cherrypick if they do not already have the "X" revision in their branch. </pre> </blockquote> That was what I meant by something being broken in his patch - it does not cleanly apply to bzr.dev. Sorry if that wasn't clear. <blockquote cite="mid:498C3C3E.4020003@arbash-meinel.com" type="cite"> <pre wrap=""> 'bzr merge' even told you that it was doing so. It is also possible that Ian did: "bzr send ../not-bzr.dev", and picked a different branch to base his changes on. Yet again, the merge directive knows exactly what base it is applying to. The idea is that if you "cd bzr.dev-copy; bzr merge ../this-patch" it should only apply the changes listed, and not the rest of "not-bzr.dev". The general workaround when you really *do* want everything in the branch *and* everything in the branch it was based on is to do: bzr branch bzr.dev-copy new_branch cd new_branch bzr pull --overwrite ../this-patch cd ../bzr.dev-copy bzr merge ../this-patch </pre> </blockquote> That is pretty much what I ended up doing, but I would expect patches submitted to the list to be able to be cleanly applied to bzr.dev, and not requiring such gymnastics. OTOH, I haven't been paying attention to the list for quite a while - perhaps things have changed. <blockquote cite="mid:498C3C3E.4020003@arbash-meinel.com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">Here is the first bug I've found - within a working tree subdirectory, I can successfully log each of the files individually, but not together. I can log both files from the working tree root. e.g. when I try ./bzr log bzrlib/remote.py bzrlib/repository.py I get the union of the logs for each file. I haven't checked in detail but superficially it looks ok. So far so good. However, if I move into the bzrlib directory and try it again I get this: ../bzr log remote.py repository.py bzr: ERROR: Path unknown at end or start of revision range: repository.py The two should be equivalent, right? </pre> </blockquote> <pre wrap=""> I assume we are just missing a 'relpath' call over the list of files. </pre> </blockquote> Probably so, I haven't had a chance to look at the code. Sounds like it can be easily fixed. I look forward to an updated patch, for both reasons. Cheers, Kent. </body> </html>