[00:40] <somerville32> bye
[00:59] <nekohayo> hello~! let's say I want to push to another computer, but this computer's files can change by themselves
[01:00] <nekohayo> will bazaar warn me of a conflict if the host has changed it files since the last push?
[01:01] <fullermd> Depends on which files you mean.  push only pushes the VCS data, it doesn't touch the working tree files one way or another.
[01:01] <fullermd> It'll notice if the remote-side VCS data has been changed.
[01:04] <somerville32> aka: It compares committed revisions
[01:08] <nekohayo> fullermd: ok thanks :) (because I just had the crazy idea of using bazaar to keep my bookmarks in synch)
[01:09] <nekohayo> fullermd: actually by vcs data, you mean stuff like "bookmarks.rdf", not the control data contained in ".bzr" right?
[01:09] <fullermd> Other way around.
[01:09] <nekohayo> arr, dang :|
[01:15] <somerville32> nekohayo, No no. You're good.
[01:15] <somerville32> Bzr is great for that
[01:16] <nekohayo> somerville32: well, if I have my laptop pushing to ~/.gnome2/epiphany/bookmarks.rdf on my desktop computer, and the desktop computer has modified its bookmarks file (without committing or anything) since then, am I not screwed?
[01:16] <somerville32> nekohayo, No.
[01:17] <somerville32> It'll merge when you attempt to commit on the desktop
[01:17] <fullermd> Not necessarily.  But it won't touch the desktop's bookmarks.rdf, it'll just update the VCS data.  You'd have to do an 'update' to bring in those changes, fix any conflicts, and then 'commit' to get the desktop's changes in the history.
[01:19] <nekohayo> fullermd: that's strange, that I need to do a bzr update... why wouldn't bzr just tell when I commit?
[01:20] <fullermd> Well, if will, if you don't update   :p
[01:20] <fullermd> And 'it', too, for those of us who can type tonite...
[03:27] <poolie_> lifeless, jam-laptop: hi
[03:27] <jam-laptop> hi poolie_
[03:27] <poolie_> should we merge this windows uninstaller fix for 0.92?
[03:27] <poolie_> it doesn't seem really critical...
[03:29] <lifeless> hi poolie_
[03:32] <jam-laptop> it doesn't seem critical either way
[03:41] <lifeless> OTOH it's low risk and alecander will probably build with it applied anyway :)
[03:56] <ubotu> New bug: #72901 in bzr-pqm "win32: can't submit via localhost" [Low,Fix released] https://launchpad.net/bugs/72901
[04:25] <ubotu> New bug: #160389 in bzr "change build process to (just) use setup.py" [Undecided,New] https://launchpad.net/bugs/160389
[04:38] <lifeless> man freenode, get the servers in order
[04:38] <jam-laptop_> that was probably just them running sort()
[05:43] <Odd_Bloke> Does a list admin have to approve my subscription to the ML?
[05:45] <fullermd> Not as a general rule, AFAIK.
[05:46] <Odd_Bloke> Hmm, just sloooowness then.
[06:28] <vila> jam-laptop__: since you're working on pqm, how about putting the commit message in the returned email indicating success/failure ?
[08:51] <Odd_Bloke> If any of the list moderators are around, there should be a couple of merge requests from D.M.Watkins@warwick.ac.uk in the pending queue.  It'd be great if they could be let through and the address whitelisted. :)
[11:02] <dato> aw pqm (r2972)
[11:58] <Enquest> I got a foo.BASE, foo.THIS, foo.OTHER files... What should i do now?
[11:58] <Arjen> Merge error?
[11:59] <Enquest> Uhm I use bzr to upload it to my web project
[12:00] <Enquest> I suppose that its a merge error
[12:00] <Enquest> What should I do with it... I can't find anything about it in the docs
[12:00] <Arjen> I'm a complete bzr noob :-)
[12:01] <Enquest> me to
[12:01] <Enquest> so anybody can explain me what I sould do with this?
[12:08] <Arjen> Enquest: What does 'bzr conflicts' say?
[12:09] <Enquest> I already did it manualy but I realy would like to know how to handle these errors
[12:09] <Enquest> thanxs Arjen (you are from holland?
[12:09] <Arjen> Yup
[12:09] <Enquest> Belgie of moet ik zeggen Vlaanderen ik weet het niet meer
[12:10] <Arjen> Well, merge conflicts which can't be handled by the VCS you'll have to fix by hand
[12:10] <Arjen> Enquest: Nederland, niet Belgie :-)
[12:10] <Enquest> aja, lage landen
[12:10] <Enquest> Werk jij proffesioneel?
[12:11] <Arjen> Dat probeer ik wel ;-)
[12:12] <Enquest> Ik ook, met wat werk jij dan? zelfstandige of voor een bedrijf?
[12:12] <Enquest> Ik ben zelfstandige
[12:12] <Arjen> Internetprovider
[12:13] <Enquest> a je programmeert niet... maar heb een isp
[12:13] <Arjen> Ja, ik programmeer voor een ISP
[12:14] <Enquest> verdiend dat wat?
[12:14] <Arjen> Genoe
[12:14] <Arjen> g
[12:15] <Arjen> But, this conversation is *way* off-topic here :-)
[12:15] <Enquest> Ok got the point... Just thought that its here dead and want to know how people manage ?
[12:15] <Enquest> sorry
[12:16] <Arjen> Merge conflicts you mean?
[12:16] <Enquest> yes
[12:17] <Arjen> If the VCS can't figure it out, then you'll have to fix the conflict(s) yourself and tell the VCS to continue
[12:28] <Odd_Bloke> Arjen, Enquest: It's not normally this dead in here, but the majority of bzr devs are Canonical employees and it's Ubuntu conference season so they're gallivanting away there. :p
[12:29] <Kinnison> :-)
[12:30] <Odd_Bloke> Enquest: Presumably you ran 'bzr merge' before getting these files.  These files mean that there was a conflict within foo that Bazaar can't handle.  If you open foo, you should see some markers where the problem is.  Edit foo so it looks as it should and then run 'bzr resolve foo'.
[12:57] <jam-laptop__> vila: that requires pqm changes, not changes to the submit plugin :)
[12:57] <vila> jam-laptop__: arf, of course silly me |-)
[12:59] <vila> but about pqm anyway, I'm still surprised that we sign a submission to merge from an url, but don't provide the revid that should be merged, leaving open a possible tip change of the submitted branch...
[13:00] <jam-laptop> vila: completely agreed, it is actually because pqm was built up around Bazaar, which would always send the full archive/category--branch--version--patch
[13:00] <jam-laptop> And it was never upgraded to recognize something different from bzr
[13:00] <jam-laptop> I actually started working on that once.... a long time ago
[13:01] <vila> haaaaa, history, as always. explain why things me *look* strange, but are, in fact, sound :)
[13:01] <vila> s/me/may/
[13:01] <jam-laptop> anyway, I'm off to breakfast, catch you around later
[13:01] <vila> same here, very busy thought :-/
[13:07] <lifeless> ola!
[13:08] <lifeless> well in principle pqm accepts url;revid=XXX
[13:08] <lifeless> except I don't think I've hooked that in
[13:14] <vila> well, I'm not that worried about the problem since only core devs can submit, but I wondered
[13:17] <lifeless> (and arch suffers here too ;)
[13:17] <lifeless> (you can replace the content of a url is the basic attack)
[15:38] <siretart> heyha bazaar hackers
[15:38] <siretart> is it possible to recreate the knit index file from a standalone knit?
[15:39] <siretart> read: I have the revisions.knit, and need to regenerate a revisions.kndx file
[15:40] <dato> abentley: I can't see in bzrtool's branch the commits for 0.92, is something wrong?
[15:41] <luks> siretart, not easily, maybe in some simple cases and using heurestics
[15:42] <luks> but .knit files don't have all the info from .kndx stored in any direct way
[15:42] <siretart> luks: I have a corrupted repository, my revisions.knit seems to be corrupted
[15:43] <siretart> zcat on revisions.knit tells me something about trailing garbage, and bzr is horribly unhappy
[15:45] <luks> hm
[15:45] <siretart> I can of course rezip the output of the corrupted revisions.knit, but then the kndx file doesn't match it :/
[15:46] <siretart> and `bzr check` doesn't seem to catch that problem
[15:46] <luks> does zcat lists the last revision info fully?
[15:46] <siretart> I cannot check what the last revision actually is
[15:46] <LeoNerd> Be aware you can't just re-compress the compressed files. They're compressed in a very special way
[15:46] <luks> last line in the .kndx file
[15:47] <luks> it has the revision-id
[15:47] <siretart> hm. the last 6 revisions seem to be missing
[15:47] <siretart> better than nothing
[15:47] <siretart> lets try to 'adjust' the .kndx file :)
[15:47] <luks> yeah, that should work
[15:49] <siretart> hm. bzr log now tells me 'no such revision.. blabla'
[15:49] <siretart> seems i need to do some more work
[15:50] <luks> /bzr/checkout/last-revision I think
[15:50] <luks> er, .bzr
[15:51] <luks> ok, no, branch/last-revision
[15:52] <dato> or revision-history for format 5 branches
[15:52] <siretart> hm. and if I remove .bzr/checkout, can I recheckout?
[15:52] <luks> no
[15:52] <luks> it needs to know the head revision
[15:52] <luks> actually, maybe you can branch -r revid:...
[15:53] <siretart> ah, lets try that
[15:54] <siretart> bzr: ERROR: bzrlib.errors.ShortReadvError: readv() read 9636 bytes rather than 19321 bytes at 0 for "revisions.knit"
[15:55] <luks> can't help with this one, not sure that exactly is bzrlib doing
[15:55] <siretart> anyway, thanks for your help
[15:56] <luks> I'd send a mail to the mailing list
[15:58] <siretart> it seems my repository is horribly corrupted :(
[15:59] <lifeless> siretart: sure it wasn't a network problem?
[16:00] <lifeless> siretart: OTOH if you were pushing over sftp, it may be the sftp bug we haven't tracked down with openssh doing the wrong thing on append from time tot time... pretty nasty
[16:36] <lifeless> jam-laptop: you've arranged to borrow the laptop?
[16:36] <jam-laptop> lifeless: yes, he said he would give it to me later today
[16:36] <lifeless> kk
[16:36] <jam-laptop> it was currently charging in his romo
[16:36] <jam-laptop> room
[16:38] <siretart> lifeless: no, all operations were local. (well, over nfs, but still using the file:// transport)
[16:39] <siretart> lifeless: I've been told now by the student that he noticed that committing still works, so he committed about 6 additional revisions
[16:40] <lifeless> siretart: so, run check :)
[16:40] <lifeless> siretart: if it's corrupt you'll probably be able to pukll from it to a backup copy to combine the work.
[16:40] <lifeless> siretart: getting to a root cause of this is very important; its possible for an NFS bug to damage things -
[16:41] <siretart> lifeless: check tells the same error
[16:41] <lifeless> siretart: when append() on fileA works, append() to file B works, but actually only file B's change gets committed over the wire it could cause this.
[16:41] <siretart> lifeless: we now decided to copy the working copy over an older repository
[16:41] <lifeless> siretart: also, using packs may be somewhat less liable to cause this sort of corruption as it has less requirements on the file system.
[16:41] <siretart> so we haven't lost any work, but some weeks of history
[16:42] <siretart> ah, great news!
[16:51] <ubotu> New bug: #160521 in bzr "specific merge algorithm for changelogs" [Medium,Confirmed] https://launchpad.net/bugs/160521
[17:21] <lifeless> jam-laptop: I'm in the hearth and kettle
[17:23] <jam-laptop> lifeless: is it hot in there?
[17:31] <ubotu> New bug: #160530 in bzr-pqm "pqm-submit is sending messages pqm doesn't understand" [Critical,Fix released] https://launchpad.net/bugs/160530
[17:41] <lifeless> jam-laptop: no
[17:41] <lifeless> jam-laptop: nor is it cold
[18:06] <Odd_Bloke> lifeless: Regarding my bundles, should I resend them with an appropriate MIME type?
[18:09] <lifeless> jam-laptop: the laptop is with me in the h&K
[18:09] <jam-laptop> ah, ok
[18:09] <lifeless> Odd_Bloke: well, I can look on BB later; but next time
[18:10] <Odd_Bloke> lifeless: OK, sure.
[18:11] <Odd_Bloke> Sorry about that.  As my email mentions, I've changed mail client.
[18:41] <schierbeck> jelmer: ka-ping
[18:41] <jelmer> schierbeck, pong
[18:42] <schierbeck> i'm not sure what the problem is with the brokenlines-optional branch
[18:42] <schierbeck> i just destroy the current treeview and draw a new one
[18:42] <schierbeck> but under all circumstances, we should support dynamically redrawing the ancestry graph
[18:43] <schierbeck> so i think it's a temporary solution
[19:00] <jelmer> re
[19:00] <lifeless> hi
[19:01] <jelmer> schierbeck: I don't think your patch is wrong, it may have regressed during gary's original rewrite
[19:01] <jelmer> 'evening lifeless
[19:01] <schierbeck> jelmer: i just wrote it
[19:02] <schierbeck> i can't find the real problem, but having a maximum width on the graph fixes it for now
[19:02] <schierbeck> and i don't think we're going to stick with the code, so it's okay to release
[19:04] <jelmer> I agree, though it's up to Szilveszter to decide
[19:05] <jaavaaguru> Hi, I've got a delta between two revisions using rev_tree.changes_from(parent_tree), and I'd like to get the full text of particular files from both revisions to pipe into an external diff tool. Can someone point me in the right direction to get the full text?
[19:10] <asabil> hi all
[19:11] <asabil> how do I use a pre-commit hook ?
[19:11] <asabil> I want to refuse commits with files with trailing spaces
[19:12] <james_w> jaavaaguru: I don't think you use the changes fr that , you get the texts from the two trees.
[19:12] <jaavaaguru> ah, ok
[19:12] <james_w> tree.get_file_text
[19:13] <jaavaaguru> thanks :-)
[19:13] <james_w> takes an id. You can get those with tree.path2id
[19:13] <jaavaaguru> I've got the IDs
[19:13] <james_w> good.
[19:14] <jaavaaguru> I've been using the Bazaar API since Saturday, and working with it has been good so far
[19:15] <jaavaaguru> I've written most of my wxWidgets GUI, and am just needing to get the text so that I can launch an external diff from the history window
[19:22] <nevans> general merging question: I did a series of merges of single changesets (e.g. using "bzr -merge ../trunk -r 1925..1926" to get r1926), but it didn't record that the changeset was merged.
[19:22] <nevans> and "bzr missing ../trunk" still shows them missing.
[19:23] <nevans> remerging ends up with a bunch of conflicts, of course.
[19:23] <nevans> should I have done that differently?
[19:24] <nevans> FWIW: I was using bzr 0.91 and bzr-svn (using 0.92rc1 now)
[19:25] <lifeless> asabil: Hi, you write a small plugin
[19:25] <lifeless> asabil: it registers with Branch.commit_hooks['precommit'] IIRC
[19:25] <jelmer> nevans: bzr doesn't track cherrypicks yet
[19:25] <lifeless> nevans: cherrypicking is a current weakness; we have a ui to express it but we don't record it(neither does hg or git FWIW)
[19:25] <nevans> jelmer: ah... I thought that was maybe what everyone meant by cherrypicks
[19:26] <nevans> git doesn't either?! wow... so what's the current "best practice" for cherrypicks?
[19:28] <nevans> lifeless: what's the cherrypicking UI called?  google isn't helping me out much.  :)
[19:29] <lifeless> nevans: you used it
[19:29] <nevans> ah.
[19:39] <jaavaaguru> james_w: that did exactly what I was looking for, thanks. I've got external graphical diff working now from my history window
[19:43] <nevans> lifeless: is http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html only a halfway solution?  (since you said git doesn't support it either)
[19:57] <lifeless> nevans: yes,
[19:57] <lifeless> nevans: cherry picks can be much more than one commit; they need to alter the behaviour of merge and log and other commands and the only system I know of that does that today is darcs.
[20:00] <nevans> lifeless: is there a bzr branch that someone is working on this currently?  or is it a little further out in the roadmap (not really specified yet)?
[20:00] <jelmer> lifeless: that reminds me, what's the status on file properties?
[20:00] <nevans> not that I intend to switch to an experimental branch anytime soon.  ;)  just curious
[20:02] <lifeless> nevans: it's a little bit out in the roadmap; I think probably in the nexxt 6 months or so.
[20:03] <nevans> lifeless: thanks
[20:38] <hendrixski> :-/ bzr-svn is able to pull svn revisions rigth? from let's say a week ago?
[20:39] <Peng> Yes.
[20:39] <jelmer> hendrixski: from svn into bzr? yes
[20:41] <hendrixski> jelmer, like instead of    svn co http://whatever -revision #12345 (not sure how to do that either)  do make a branch of a revision from last week
[20:42] <jelmer> oh, sure - you can use -r
[20:42] <hendrixski> oh
[20:43] <jelmer> ah, you mean revspecs of dates?
[20:43] <jelmer> hmm, that I'm not sure
[20:43]  * hendrixski tries that
[20:43] <jelmer> it may work, but I haven't ever tested it
[20:43] <hendrixski> oh
[20:43] <hendrixski> well, I'll play around with it :-)
[20:44] <nevans> jelmer: is there a way to see/use the SVN changeset number rather than the various bzr revisionspecs?
[20:46] <jelmer> nevans: the revision id for svn revisions contains the svn revno
[20:46] <nevans> it would be useful if there were a revspec like "svn:123456"
[20:47]  * hendrixski now knows that the word to google for is "revisionspecs"
[20:47] <jelmer> nevans: please file a bug report :-)
[20:47] <nevans> ah... so it does.  bzr log --show-ids is useful
[20:47] <nevans> jelmer: I think I will.  :)
[20:48] <nevans> jelmer: oh, and as an aside... THANKS for bzr-svn.  it rocks.  :-)
[20:49] <jelmer> thanks :-)
[20:50] <hendrixski> yeah.. I think bzr-svn is going to save me a ton of headaches in the near future
[20:51] <hendrixski> if I can quickly learn how to use it :-/
[20:57] <hendrixski> hhhmm... yeah, for bzr .90, the    bzr branch http://svn.source/directory date:2007-10-25    doesn't seem to work  I guess it has a different date structure than svn :-(
[20:58] <nevans> launchpad was giving me some weird timeout errors, so I didn't search to see if there was a duplicate before adding my bug.
[21:03] <nevans> hendrixski: your problem is that you want to get working tree for a particular svn revision number, right?
[21:03] <hendrixski> nevans, yup
[21:03] <hendrixski> though, I'm probably just putting them in the wrong order
[21:04] <nevans> you do that by first doing a checkout of HEAD from svn, using that to figure out what the bzr revno will be, and then branch from the bzr HEAD to a new branch (using -r bzr_rev_number)
[21:05] <nevans> a little bit indirect.  but it should work
[21:06] <nevans> to quickly get the bzr revision-id, you could do "bzr log --show-id | grep 29853"
[21:07]  * hendrixski is confused
[21:08] <nevans> sorry
[21:08] <hendrixski> nevans, not your fault... I'm a total noob
[21:08] <nevans> so you want to do "svn co http://whatever -r 12345"...
[21:08] <nevans> what you could do instead:
[21:09] <nevans> bzr co svn+http://whatever/trunk trunk
[21:10] <hendrixski> right, so that's the head of trunk, right?
[21:10] <nevans> then cd into trunk, and do "bzr log --show-id | grep 12345" to find out what the bzr revision id is
[21:10] <nevans> yep
[21:10] <hendrixski> ah
[21:10] <hendrixski> ok
[21:10] <nevans> then, with the revid in hand:
[21:11] <nevans> bzr branch -r revid:svn-v3-trunk1:0487d25d-142b-0410-8fcf-b82ac621bf97:blahblahblah:12345 ../branched_from_12345
[21:11] <hendrixski> ah... Ok, because those things are more complex than just the revision number  I see
[21:12]  * hendrixski is still waiting for head of trunk to download
[21:12] <nevans> BTW, it will go faster and use less disk space if you are using a shared-repository... but if you are just starting with bzr, you should probably wait until you are comfortable before you start working with that
[21:12] <hendrixski> I'm totally just starting
[21:12] <nevans> hendrixski: yep.  and that is why I asked jelmer if there was a svn revisionspec.  :)
[21:14] <hendrixski> ah
[21:14] <nevans> presumably, if there was, the entire ordeal could be shortened to just "bzr checkout svn+http://whatever -r svn:12345"
[21:15] <hendrixski> in a perfect world I suppose
[21:15] <hendrixski> hah, whadya know... the revision numbers are totally different than what I see on trac
[21:16] <hendrixski> I thought I was supposed to be getting revision # 1480? but it's only actually up to 103
[21:16] <nevans> hendrixski: same sort of issue
[21:16] <hendrixski> yup
[21:16] <hendrixski> oh man, no manual would ever have shown me that...
[21:17] <nevans> bzr has quite a few ways of addressing a revision... none of them as simple as svn's "global" (per repo) changeset id
[21:17] <nevans> bzr help revisionspec
[21:18] <hendrixski> yeah, knowing the word for it (revisionspec) helps a lot too :-p
[21:18] <nevans> in svn, the revno is global through the entire repository (all projects, branches, tags, etc).  in bzr, it is for just that branch.
[21:18] <nevans> hendrixski: the only way I know the word for it is "bzr help topics"  ;)
[21:20] <ubotu> New bug: #160607 in bzr-eclipse "seting plugin path in bzr settings breaks bzr support" [Undecided,New] https://launchpad.net/bugs/160607
[21:24] <hendrixski> hhmm... bzr branch -r revid:102 ../New/
[21:24] <hendrixski> bzr: ERROR: Not a branch: /home/******/Desktop/officialBranch/New/
[21:25]  * hendrixski will figure this out  :-)~
[21:26] <nevans> hmm... I had it wrong... you need to give it both to and from URLs (or just a from)
[21:26] <nevans> bzr branch FROM TO -r 102
[21:26] <nevans> bzr branch -r revid:102 . ../New/
[21:28] <fullermd> You almost certainly don't have any revisino with the revid 102...
[21:28] <hendrixski> nevans, you are THE MAN!!!!
[21:28] <nevans> :)
[21:28]  * hendrixski does a little dance as the earlier revision downloads :-)
[21:30]  * hendrixski is done dancing 
[21:30] <hendrixski> So then I guess the problem was that I assumed that the wrong thing was the actual revision number, I have to get the HEAD first, browse through which revisions exist, and *then* I get the right revision number and DL it
[21:30] <hendrixski> which is what nevans said in the first line
[21:30] <hendrixski> but I didn't understand it until after I tried it
[21:30] <hendrixski> sweet
[21:30] <nevans> yeah... revision numbers mean completely different things to svn and bzr
[21:31] <hendrixski> I see
[22:40] <ubotu> New bug: #160626 in bzr "need to suppress upgrade warning" [Undecided,New] https://launchpad.net/bugs/160626
[23:03] <jodal> Hi! We're having problems with a repository used with 0.17 (etch) and 0.90 (gutsy). seemingly randomly, we get KnitCorrupt errors at some commits, and also at checkout of the entire branch: http://dpaste.com/24408/
[23:04] <jodal> any tips?
[23:16] <abentley> dato: Those commits should be there now.
[23:27] <lifeless> hi abentley
[23:28] <abentley> Hi there.
[23:28] <lifeless> kindof a shame to be int he same TZ but so busy we don't get much time to chat
[23:33] <lifeless> speaking of which, time to grab my jacket for dinner