[12:08] <lifeless> radix: you can't unmerge
[12:08] <lifeless> radix: you need to commit the reverse change; then later use a reverse-merge of your commit that reversed it out
[12:09] <lifeless> hsn_: cscvs should be able to convert for you in that case
[12:09] <radix> I think I just figured out how to do it
[12:11] <radix> lifeless: what I did was: cd $TRUNK; bzr merge -r 430..429 .; bzr commit -m "unmerge $CRAPPY_BRANCH"; cd $CRAPPY_BRANCH; bzr merge $TRUNK; bzr revert *; bzr commit -m "HACK commit: merge unmerge without textual changes"
[12:11] <radix> lifeless: now $CRAPPY_BRANCH is mergeable to trunk again
[12:12] <radix> (making sure that $CRAPPY_BRANCH and $TRUNK were both up-to-date with other unrelated $TRUNK changes first)
[12:14] <radix> lifeless: is that how you would've done it?
[12:14] <radix> (I'm not sure if that's what you meant by "reverse-merge"
[12:19] <abentley> lifeless: pong
[12:21] <hsn_> lifeless: you are talking about this? http://www.gnuarch.org/gnuarchwiki/cscvs
[12:22] <abentley> radix: "bzr merge -r 430..429 ." is an example of "reverse merge".
[12:22] <radix> ah, ok
[12:23] <radix> so yeah, that's the obvious thing: it's the "merge *that* reverse merge, and then revert the textual changes" that's the tricky bit
[12:25] <lifeless> radix: thats close enough
[12:26] <lifeless> abentley: hi, tree-reference's always have a reference-revision, its never NULL right ?
[12:26] <lifeless> erm None
[12:26] <lifeless> (at inventory serialisation)
[12:26] <lifeless> hsn_: no, http://launchpad.net/cscvs
[12:26] <abentley> Yes.
[12:26] <lifeless> good; I've just grabbed another 10-15% on xml serialisation
[12:27] <lifeless> I gambled I had it right :)
[12:27] <abentley> It should be the value of the contained tree's last_revision.
[12:27] <lifeless> I've made the serialiser aware of what attributes each kind should have
[12:27] <lifeless> so it now requires that field to be non-none on tree-reference kinds, and ignores it otherwise.
[12:29] <abentley> Sounds good.
[12:29] <lifeless> unfortunately my time looking into that was a little wasted as there is only a second total to win there
[12:30] <lifeless> so I grabbed something like 100ms if I merge it into the pack branch; worth it but not big
[12:34] <hsn_> bzr get http://bazaar.launchpad.net/~launchpad/launchpad-cscvs/rocketfuel fails with bzr: ERROR: bzrlib.errors.KnitHeaderError: Knit header error: '\x1f\x8b\x08\x...
[12:34] <poolie> hello
[12:35] <poolie> hsn_, is that a public branch?
[12:35] <lifeless> poolie: yes
[12:35] <lifeless> poolie: we open sourced our cscvs changes
[12:38] <abentley> lifeless: well, blow me down.  I thought I'd never see the day.
[12:40] <radix> didn't that happen like half a year ago?
[12:40] <lifeless> yes
[12:40] <lifeless> abentley: about 12 months ago IIRC
[12:40] <radix> welcome to 2007 guys ;-)
[12:43] <luisbg> UnlockableTransport: Cannot lock: transport is read only: <bzrlib.transport.http._urllib.HttpTransport_urllib ...
[12:43] <luisbg> why? and why in a commit?
[12:43] <poolie> because you're trying to commit to an http branch
[12:43] <poolie> you may have used checkout when you wanted to use 'branch'
[12:45] <lifeless> luisbg: when you checkout, bzr commit pushes the results back to the place you checked out - like svn/cvs
[12:46] <lifeless> luisbg: but http is readonly, so it fails. You can either bind to a writable url, if working like svn is what you wanted, or you can unbind to give yourself a stand alone branch, which will operate independently of the source branch
[12:46] <luisbg> poolie, you are correct... I did the mistake of checking out and not branch :S
[12:47] <luisbg> how do I fix this withour erasing and branching?
[12:47] <poolie> i think just saying 'bzr unbind' in that directory will do it
[12:47] <luisbg> lifeless, how do I unbind?
[12:47] <luisbg> ahhh cool
[12:57] <NfNitLoop> Hmm.   Tried to check branch a bzr-svn repo onto a windows box, and got an error:
[12:57] <NfNitLoop> bzr: ERROR: File exists: u'<shared-repo>/.bzr/repository/knits/c1': [Error 183]  Cannot create a file when that file already exists
[12:57] <NfNitLoop> s/check branch/branch/
[12:58] <lifeless> hmm, why does osutils.split_lines exist, isn't s.splitlines(True) the same ?
[12:58] <lifeless> NfNitLoop: is c1 a file or directory?
[12:59] <igc> morning all
[12:59] <lifeless> hi
[01:02] <abentley> lifeless: No.
[01:02] <abentley> s.splitlines() will also split on \r or
[01:02] <abentley> \r\n
[01:03] <lifeless> abentley: ah thanks. we should note that
[01:04] <lifeless> oh, and
[01:04] <lifeless> 0.92: first post!
[01:04] <abentley> It is precisely this issue that made me uncomfortable with your recent patch.
[01:04] <lifeless> me too :(
[01:04] <abentley> Because people don't tend to realize that.
[01:05] <abentley> I think the final patch handled it pretty well, though.
[01:07] <lifeless> cool
[01:14] <NfNitLoop> lifeless: a directory.
[01:15] <lifeless> NfNitLoop: thats strange then
[01:15] <lifeless> NfNitLoop: perhaps the exception raised by python has changed, wasn't alexander mentioning something like that last week ?
[01:16] <lifeless> (we expect mkdir to fail when the dir is already made so we catch an exception there)
[01:16] <NfNitLoop> NfNitLoop: Not that I recall... but I only vaguely keep watch in here.
[01:31] <lifeless> NfNitLoop: what version of python do you have ?
[01:31] <NfNitLoop> 2.5.1
[01:31] <lifeless> can you try with 2.5.0 ?
[01:31] <luisbg> poolie, and lifeless, thanks a lot =)
[01:32] <NfNitLoop> lifeless: Hmmm.    I guess so... I can install it in its own directory, right?
[01:32] <lifeless> I think so
[01:35] <NfNitLoop> downloading.  lallaa.
[01:36] <NfNitLoop> I'm looking forward to svn 1.5 when the python bindings will be fixed across all platforms. :p
[01:36] <NfNitLoop> I'm not going to build my own on my windows box.
[01:37] <NfNitLoop> So until then I'm (trying) branching off of my linux box to the windows one.  all commits back to svn will have to go back through the linux box.
[01:38] <NfNitLoop> a bit of a pain, but it's still awesome that that's a viable workflow.  :)
[01:44] <lifeless> spiv: is chain C or python ?
[01:47] <NfNitLoop> lifeless: same error with 2.5.0
[01:48] <NfNitLoop> lifeless: I've successfully done this from Linux -> OSX
[01:48] <NfNitLoop> I'm actually now doing it from OSX -> WinXP.  Since my mac laptop is handily located next to my computer here. :)
[01:48] <spiv> lifeless: chain?
[01:49] <NfNitLoop> so it seems a windows-specific issue.
[01:49] <spiv> lifeless: you mean functools.partial?
[01:50] <NfNitLoop> where does .bzr.log go in WIndows?
[01:53] <lifeless> NfNitLoop: bzr version will tell you
[01:53] <lifeless> spiv: itertools.chain
[01:53] <lifeless> NfNitLoop: please file a bug
[01:53] <lifeless> NfNitLoop: you can work around by copying the .bzr directory by hand
[01:53] <spiv> lifeless: everything in itertools in CPython is implemented in C.
[01:53] <lifeless> spiv: thanks
[02:16] <Ubotu> New bug: #139253 in bzr "bzr branch fails with "File exists" error." [Undecided,New]  https://launchpad.net/bugs/139253
[02:25] <Ubotu> New bug: #133989 in bzr-svn "svn-import reports a File exists error (dup-of: 139253)" [Undecided,New]  https://launchpad.net/bugs/133989
[04:18] <AfC> Would it be correct to say that Bazaar doesn't depend on RCS (as Git does) because Bazaar has more advanced (ok "different") algorithms for doing and presenting diffs?
[04:21] <poolie> really, Git depends on RCS?!
[04:21] <poolie> it is correct anyhow
[04:22] <poolie> we have a diff algorithm described by Bram Cohen as "by far the best" or something similar
[04:22] <poolie> (lunch)
[04:25] <AfC> poolie: apparently the Debian package does. I seem to recall seeing that from the Git pages.
[04:25] <AfC> Needless to say, I'm going to blog a one liner about that if I can verify my facts.
[04:25] <Ubotu> New bug: #139273 in bzr "test case leaves behind temporary log files" [Low,Triaged]  https://launchpad.net/bugs/139273
[04:30] <AfC> Maybe it's just the cogito UI that depends on it. Oh well.
[04:41] <jelmer> the GNOME DistributedSCM page says bzr is lacking guaranteed content history, is that true?
[04:51] <lifeless> what does that mean ?
[04:52] <igc> it means we don't look up revisions via SHAs I think
[04:53] <lifeless> we have testaments, they can be signed
[04:54] <jelmer> I'm not quite sure what it means. Also talks about (disk?) corruptions in the repository and stuff
[04:54] <lifeless> really, is this imaginary or experienced ?
[04:55] <asabil> jelmer: I think the whole sha1 thing started with monotone
[04:56] <asabil> monotone does heavy checking and verification on the changesets, and the consistensy of its sqlite database
[04:57] <asabil> this can make some sense, because it allows you to know if you database is corrupted (for example after storing it for 5 years on an optical disk)
[04:58] <lifeless> we have that
[04:58] <lifeless> for content we know the sha
[04:58] <jelmer> lifeless: looks like somebody confused revids with checksums somewhere
[04:58] <asabil> it also allows to detect if someone was trying to do some funky stuff with a database (trying to corrupt it for example)
[04:58] <lifeless> for the content of the tree we have a sha of that
[04:59] <lifeless> jelmer: is it a wiki page, can you correct it ?
[04:59] <asabil> yes it is a wiki page, I have been updating it recently
[05:00] <asabil> (I have to admit that there is a huge bias in that page toward git unfortunately :'( )
[05:01] <jelmer> lifeless: yeah, sure, I'll add a comment
[05:01] <jelmer> hey, I didn't know git was slower than both bzr and hg on windows...
[05:01] <lifeless> not surprising
[05:01] <lifeless> git is awful tuned in its design to what linux and ext3 do from everything I've read
[05:02] <igc> btw, on Wikipedia, signed revision support is listed as 'partial' for Bazaar: see http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Features
[05:02] <lifeless> someone needs to write better verification support is all; not huge or hard
[05:03] <lifeless> asabil: are you a git advocate? or bzr?
[05:03] <igc> this whole area was heavily pushed by Linus in his Google talk video as well
[05:03] <asabil> lifeless: I bloody hate git
[05:03] <lifeless> :)
[05:04] <asabil> I have been trying to keep the page unbiased, but there is too much hype around git
[05:04] <asabil> it's life a fashion thing
[05:04] <lifeless> :(
[05:04] <jelmer> lifeless: still, it's main design goal is speed and it's written in C so I'd expect it to be faster
[05:05] <asabil> I am really wondering if the FOSS community is turning into some fashion oriented community
[05:05] <lifeless> jelmer: C is not a panacea; I agree that their priorities are broken
[05:06] <mneptok> asabil: check out my new Yves Saint-Laurent wireless card!
[05:06] <asabil> lol
[05:07] <mneptok> binary blob drivers, though. they don't want to reveal the WPA subroutine code or the floral extracts they use. :/
[05:08] <asabil> oh
[05:08] <asabil> lol
[05:09] <mneptok> yeah. "free as in cologne." :/
[05:10] <asabil> jelmer: I was the one putting that bzr is lacking revision verification
[05:10] <igc> asabil,jelmer,lifeless: there aren't a lot of responses (~100) but I'm a little surprised by the results to date of the Bazaar user survey: http://www.surveymonkey.com/sr.aspx?sm=FDeDsLzaZ0AKNEATuA0QklWayMZKGfHcrP1U4V55jAY%3d
[05:10] <asabil> I removed it now
[05:10] <lifeless> asabil: so we have shas from the revisions down; we have a canonical form that gets signed called a testament
[05:10] <jelmer> asabil: cool, thanks
[05:11] <igc> neither Git nor Hg are as liked as much as Subversion by Bazaar users
[05:11] <lifeless> asabil: revision ids are not shas because that forces history rewriting if you want partial conversions to be interoperable (e.g. its fugly)
[05:11] <jelmer> lifeless: Writing in C may not necessarily make something faster, but writing things on a lower level usually makes it easier to optimize
[05:11] <jelmer> (no conversion for bindings involved, no byte-compilation, etc)
[05:11] <lifeless> jelmer: I find the reverse :)
[05:11] <igc> despite that fact that "distributed" is a major reason for choosing Bazaar
[05:12] <lifeless> jelmer: After one accounts for the baseline speed difference, I find it easier to make something in python twice as fast as to make something in C twice as fasst
[05:12] <lifeless> igc: this is something to put on the Gnome vcs page I think
[05:12] <lifeless> asabil: ^ jelmer: ^
[05:12] <mneptok> igc: "What I basically want is the exact same thing, but completely different? Can you do that?"
[05:12] <lifeless> mneptok: "Yes"
[05:12] <mneptok> *bounce*
[05:12] <asabil> lifeless: http://live.gnome.org/DistributedSCM
[05:13] <asabil> you can read and suggest updates
[05:13] <lifeless> asabil: I'm going to let others do that
[05:13] <lifeless> right now I'm fighting the key performance battle that currently we're whipped at
[05:13] <asabil> lifeless: yeah I can do it, just give me some feedback
[05:13] <asabil> igc: lol, I am the only one who voted that I know monotone the best :D
[05:13] <mneptok> -e
[05:14] <asabil> :)
[05:14] <jelmer> I'm only adding comments, won't change any actual data..
[05:14] <jelmer> igc: I'm surprised at the amount of Windows users
[05:15] <igc> jelmer: yes, there are quite a few surprising results in there
[05:16] <lifeless> what, less users than you expected?
[05:17] <lifeless> We decided windows was strategic way back
[05:17] <jelmer> lifeless: I always tend to write faster code in C if I write it twice in both Python and C
[05:17] <jelmer> lifeless: no, more
[05:17] <jelmer> lifeless: 39% (out of 95 people)
[05:18] <jelmer> (people can select multiple os'es)
[05:18] <lifeless> that feels right to me
[05:19] <jelmer> beats everything but ubuntu
[05:31] <lifeless> igc: call ?
[05:32] <igc> sure
[05:32] <igc> one minute
[06:13] <lifeless> igc: split_lines on inventory is 100msec
[06:14] <Stevage> Question: if you rename a versioned subdirectory manually (eg, "ren foo bar" in windows), is bzr supposed to detect that and do something appropriate?
[06:16] <lifeless> Stevage: no, but 'bzr rename --after foo bar' should tell bzr about it for you
[06:17] <lifeless> Stevage: I think if you have the bzr tortoise plugin I'd expect bzr to be told, or something appropriate
[06:17] <Stevage> cool. the documentanio for 'commit' is a bit misleading then
[06:17] <Stevage> there's a bzr tortoise plugin??
[06:17] <Stevage> cool :)
[06:18] <lifeless> Stevage: hmm, can you point at the misleading bit ?
[06:18] <Stevage> http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#commit
[06:18] <Stevage> the example at the end of that
[06:18] <Stevage> It says "In the example above, the last commit will fail by design. This gives the user the opportunity to decide whether they want to commit the rename at the same time, separately first, or not at all."
[06:19] <Stevage> I took that to mean bzr will detect the rename and commit it.
[06:19] <Stevage> but actually all that happens is it detects a deletion and an unknown file.
[06:19] <lifeless> well
[06:19] <lifeless> if you look at the example 'bzr mv' is used to do the rena,e
[06:19] <Stevage> oh!
[06:19] <Stevage> yeah oops you're right
[06:19] <Stevage> thought it was just mv
[06:19] <lifeless> ":)
[06:20] <Stevage> I still don't get this text from the front page though:
[06:20] <Stevage> For that reason, Bazaar is specifically engineered to be as tolerant of user decisions as possible, and to allow ANY operation on your code tree that is possible using UNIX and Windows filesystems. As a primary example, Bazaar is extremely tolerant of renames of directories and files, even when multiple different contributors are renaming files and directories differently in their branches,...
[06:20] <Stevage> ...and then merging from one another.
[06:21] <Stevage> that was what originally got me thinking that somehow you could just rename files at will and it would detect it
[06:29] <lifeless> Stevage: ah
[06:30] <lifeless> Stevage: what we mean is 'when two users of bazaar perform renames [using bazaar]  in separate branches, we try very hard to Do The Right Thing'
[06:30] <lifeless> what you are trying to do, we are also tolerant of, but we clearly don't /know/ whats happened if you don't tell bzr about it. We can guess, but that generally gives worse results
[06:43] <Stevage> yeah, I guess I was just confused by the references to unix/windows filesystems, followed immediately by [Bazaar]  renames.
[06:44] <Stevage> it's all good.
[06:49] <Stevage> is there a way to commit with a date other than today's? (other than changing the system clock...)
[06:50] <poolie> Stevage, there is at the api level, i don't know if it's exposed on the cli
[06:51] <poolie> rather i think it's not
[06:51] <poolie> it would be a trivial addition
[06:51] <Stevage> hmm
[06:51] <Stevage> I'm trying to do a quick and dirty repository migration here
[06:51] <Stevage> might be easier to just set the system clock, but that can have ugly side effects
[06:53] <poolie> that doesn't sound like a really great idea...
[06:53] <Stevage> yeah I know :/
[06:53] <Stevage> what do I need to compile/build bzr on winxp?
[06:54] <poolie> if you just want to modify the python source you only need python
[06:55] <poolie> if you want to build the binarios, see http://bazaar-vcs.org/Win32ReleaseChecklist
[06:55] <poolie> or rather http://bazaar-vcs.org/BzrWin32Installer
[06:55] <lifeless> Stevage: what format are you trying to convert from ?
[06:55] <Stevage> from this ancient system called TLIB
[06:55] <lifeless> oh wow, ok
[06:55] <lifeless> in python
[06:56] <lifeless> if you do 'import bzrlib.workingtree'
[06:56] <lifeless> tree = bzrlib.workingtree.WorkingTree.open('path')
[06:56] <Stevage> poolie: what do you mean by building binaries? if I'm just rebuilding it for my own purposes, what will I need?
[06:56] <lifeless> tree.commit(message=... )
[06:56] <Stevage> sadly I don't know python at all (yet)
[06:56] <lifeless> there are parameters (pydoc bzrlib.commit.Commit lists them all)
[06:56] <poolie> Stevage, just python will do, there is no compilation step
[06:57] <Stevage> so the python dll that came with bzr is sufficient?
[06:57] <lifeless> poolie: well, there is an optional one ;)
[06:57] <Stevage> or is there an interpreter?
[06:57] <poolie> yes, there's an interpreter
[06:57] <poolie> i should have said, there's no mandatory compilation step
[06:57] <poolie> if you run the command 'python'
[06:57] <Stevage> but if i want to be able to run 'bzr commit' etc from the commandline I'll need to compile?
[06:58] <poolie> no
[06:58] <poolie> do you have bzr installed from a package at present?
[06:58] <Stevage> this is xp
[06:58] <poolie> i mean, from one of the windows installers
[06:58] <Stevage> yeah
[07:03] <lifeless> later all
[07:15] <Stevage> ok, so now that I have python installed, how do I compile/interpret bzr?
[07:49] <Stevage> can anyone help me get started running bzr from source on winxp?
[07:51] <beuno> Stevage, I believe now you just have to execute the "bzr" in the folder where the source is
[07:52] <Stevage> come to think of it I don't think I actually have the source
[07:53] <Stevage> I have /lib and /doc but no /source or anything
[07:53] <beuno> Stevage, were did you download it from?
[07:53] <Stevage> bazaar-vcs.org, the 'windows standalone installer' link
[07:53] <abentley> SteveA: You should have 'bzrlib', not 'lib'.
[07:53] <Stevage> it's called lib for me
[07:54] <Stevage> in lib there are some .pyd's, a .zip and a .dll
[07:54] <abentley> It doesn't sound like you're taking the run-from-source steps.
[07:54] <spiv> The standalone installer doesn't install the source AFAIK.
[07:54] <beuno> Stevage, if memory serves me right, you should be able to fire up a command line prompt and execute "bzr", you should know it's a command-line program
[07:54] <Stevage> no, I wasn't - I originally downloaded the binaries. now I realise I need the source too.
[07:55] <abentley> All you need is the bzr tarball and python.
[07:55] <Stevage> yeah that's ok, I've had bzr running for a couple of days. it's just now that I want to modify the source...
[07:55] <spiv> It installs the compiled .pyc files bundled into a zip file I think.
[07:55] <abentley> Compiling is an optional step-- it increases performance a bit.
[07:55] <beuno> Stevage, then you should download http://bazaar-vcs.org/releases/src/bzr-0.90.tar.gz
[07:55] <Stevage> yeah just got that
[07:56] <abentley> But that's all compiling does.
[07:56] <beuno> Stevage, then uncompress, edit, go into the folder and execute "bzr", that should be it
[07:56] <beuno> it doesn't need to be compiled to work
[07:57] <beuno> as abentley mentioned, all that does is speed things up a bit
[07:57] <Stevage> erm, I'm on windows here, that's not going to work
[07:57] <Stevage> bzr. is a shell script
[07:57] <beuno> Stevage, it's a python script, it should run fine
[07:58] <beuno> if it doesn't, then try "python bzr"
[07:58] <Stevage> ok that worked
[07:59] <beuno> :D
[07:59] <Stevage> there should be a bzr.bat included, since that package is supposed to work on all platforms
[07:59] <beuno> surprising how much effort the bzr devs here put into multi-platform compatibility
[08:00] <beuno> Stevage, it does, and a .bat would be windows-specific
[08:00] <Stevage> yeah but there's a "bzr." which is unix specific...?
[08:00] <abentley> Well, that's bundled with windows installers.
[08:00] <beuno> Stevage, nope, the tarball you downloaded is the same for all platforms
[08:00] <Stevage> yeah I know
[08:00] <abentley> Sticking it in the main source tree wouldn't kill us, though.
[08:01] <Stevage> I'm just saying, there's a unix shell script, but no windows batch file
[08:01] <abentley> No, there's no shell script.
[08:01] <beuno> Stevage, there isn't a unix shell script, it's a python script
[08:01] <abentley> There's only a python script.
[08:01] <abentley> The .bat file is just a more convenient way of running that python script.
[08:02] <Stevage> heh, ok it's a python script that starts with #! /usr/bin/env python
[08:02] <Stevage> which is code understood by the unix platform but not by windows
[08:02] <Stevage> hence, "unix script"
[08:02] <Stevage> it doesn't matter anyway
[08:02] <abentley> Shell scripts start with #!/bin/sh
[08:02] <beuno> but you seemed to convince abentley to add the .bat in the main tree, so you made progress  ;)
[08:02] <Stevage> lol
[08:03] <abentley> Stevage: The last VCS I worked with started as a collection of shell scripts.  It wasn't pretty.
[08:03] <Stevage> ok so where do I look to add a new command line argument?
[08:03] <Stevage> ugh
[08:04] <Stevage> you should see what I'm migrating from, it considers directory trees an "advanced feature"
[08:04] <beuno> g'night all
[08:04] <abentley> You would edit bzrlib/builtins.py and find cmd_commit.
[08:07] <Stevage> awesome
[08:07] <Stevage> if there's a .pyc should I delete it?
[08:07] <Stevage> or will it recompile itself automatically?
[08:08] <abentley> It will recompile automatically.
[08:10] <Stevage> hey awesome I added a new option and it worked :)
[08:10] <Stevage> (well, it doesn't do anything yet...)
[08:11] <Stevage> Usage:   bzr commit [SELECTED...] 
[08:11] <Stevage> Options:
[08:11] <Stevage>   -h, --help            Show help message.
[08:11] <Stevage> ...
[08:11] <Stevage>   --date=COMMITDATE     Commit as if it were this date.
[08:15] <Ubotu> New bug: #139247 in launchpad-bazaar "bzr+ssh:// cannot be used to branch" [Low,Invalid]  https://launchpad.net/bugs/139247
[08:18] <Stevage> where would I go to add the implementation of that option?
[08:19] <Stevage> oh, commit.py duh :)
[08:28] <lifeless> well commit.py already has it
[08:28] <lifeless> you just need to glue it into the parameters passed to workingtree.commit() in builtins.py
[08:29] <lifeless> e.g. all your changes will be in builtins.py + any test changes
[08:54] <Stevage> ok. I'll need to parse a date from the command line, but I can't understand how to add that code to Option.py
[08:54] <Stevage> is there already a date parsing function?
[09:07] <poolie> Stevage, i believe there is one in the time module
[09:07] <poolie> Stevage, http://docs.python.org/lib/module-time.html
[09:07] <poolie> see strptime
[09:14] <Stevage> ok just found that
[09:14] <Stevage> so how does the option parsing stuff work: when an option is set to type 'str', where is the call that makes it get parsed as a string?
[09:14] <Stevage> and what is 'str' - an enum, or a language primitive?
[09:14] <Stevage> (I don't know Python at all :( )
[09:34] <igc> heading off a bit earlier today
[09:34] <igc> night all
[10:45] <Ubotu> New bug: #139318 in bzr "`bzr send --mail-to` failed with UnicodeEncodeError" [Undecided,New]  https://launchpad.net/bugs/139318
[11:29] <pitti> hello all
[11:29] <pitti> since the last upgrade of bzr (0.18 to 0.90), pulling from a bzr+ssh:// fails with [Errno 13]  Permission denied: '/.bzr.log'
[11:30] <pitti> is that me doing something silly?
[11:30] <pitti> pulling from sftp:// or http:// works
[11:30] <pitti> might also be a problem on the remote end (bzr+ssh://bazaar.launchpad.net)
[11:31] <pitti> indeed, pull bzr+ssh:// from my own server works
[12:34] <matkor> Assuming I have checkout of branch. I want to know if I am up to date with checkout - is it bzr missing <checkout_branch> right way of checking it ?
[12:49] <Lo-lan-do> matkor: I think you can just do "bzr missing"
[01:07] <matkor> Lo-lan-do: I get bzr: ERROR: No peer location known or specified in 0.90
[01:08] <Lo-lan-do> Hm.  Then yeah, use the full syntax :-)
[01:09] <matkor> Lo-lan-do: Thnx :)
[01:24] <matkor> I think I will fill wishlist about that if it so obvious ...
[01:29] <matkor> It is so obvious so there already is wishlist about that ;)
[02:01] <matkor> I Have checkouted my WT to revno 50. But it indroduces errors. Can I have it back to revno 49 ? TIA
[07:11] <jelmer> james_w, siretart: are there any plans in merging the hooks branch for bzr-builddeb?
[07:31] <BasicOSX> doing a bzr checkout --light-weight, is there a way to convert(?) that to a full branch?
[07:32] <jelmer> BasicOSX: A patch was posted to the mailing list yesterday that adds support for doing that
[07:32] <jelmer> I don't think it's possible in a released version yet
[07:33] <BasicOSX> that's actually "good" since I as pounding my head abou tit
[07:59] <Jen> Hi, I just found Bazaar and is trying it out locally. I read this (great) guide (http://doc.bazaar-vcs.org/latest/en/user-guide/centralized_workflow.html#initial-setup) and is wondering if there is any way to perform a 'hook like' command. When commiting I would like 'centralhost' to update to an folder placed in the webscope.
[08:02] <beuno> Jen, sure, you can write a plugin for that
[08:02] <beuno> their are plenty of existing plugins: http://bazaar-vcs.org/BzrPlugins
[08:03] <beuno> you can look at one of those for examples
[08:05] <Jen> beuno: Great. Thank you. Am I right that I whould have to do something like 'bzr checkout sftp://server/tree/branch /webroot/folder' and then 'bzr pull sftp...' when updating?
[08:06] <Lo-lan-do> The URL should be remembered, so just "bzr pull" should work.
[08:06] <beuno> Jen, if you want to have a svn-like workflow, yes
[08:06] <dato> I think it's bzr update for checkouts.
[08:07] <Jen> beuno: oh my bad that's wrong. That will checkout the branch to my computer - I would like it to be checked out to a folder on the central server
[08:08] <Jen> dato: thanks ;)
[08:09] <james_w> jelmer: it needs updating. If you have a need for it then I can move it up the TODO list.
[08:10] <james_w> Jen: either ssh to the server and checkout, or you can supply sftp://... as the second argument and do it remotely.
[08:10] <beuno> Jen, you would like to checkout from your PC to a directory on another PC?
[08:11] <james_w> however that will be slow if both ruls are remote. If they are on the same server then doing it after ssh to the server will be a lot faster.
[08:11] <jelmer> james_w: There's some C-based packages I have it would be very useful for
[08:12] <james_w> and using bzr+ssh:// will speed it up.
[08:12] <james_w> jelmer: you wanted to run autotools correct?
[08:12] <jelmer> james_w: yep
[08:13] <Jen> beuno: no - when I commit I would like 'centralhost' to do a checkout to itself (i.e. move the files to a webscope)
[08:13] <james_w> jelmer: on a native package?
[08:14] <jelmer> james_w: nope, in normal mode (with export-upstream)
[08:14] <beuno> Jen, right, I understand, you can hook it and make it do that, it will take some work to make everything run smoothly (specifying where it should checkout, por example), but it's perfectly doable
[08:14] <james_w> jelmer: was your need satisfied by the old branch? I don't even remember if it worked at all for you.
[08:14] <jelmer> james_w: yeah, that worked, though I'd rather just specify the command to be run rather than having to create scripts
[08:15] <Jen> beuno: great - thanks for your time
[08:15] <jelmer> the use case for hooks probably differs per person though..
[08:15] <james_w> jelmer: in a config file?
[08:15] <jelmer> james_w: yeah
[08:15] <beuno> Jen, no problem, have fun with that  :D
[08:16] <jelmer> just 'export-upstream-hook = ./autogen.sh' in the same place as where the other bzr-builddeb settings are
[08:16] <james_w> jelmer: I'm not sure how easy that would be to authenticate, but it seems like a reasonable request.
[08:16] <jelmer> james_w: where is the authentication stuff for exactly? Don't you have to trust the data in the branch anyway?
[08:17] <james_w> I'm not sure how important authentication is as you have to run debian/rules anyway, but I wanted to avoid the surprise of having a hook run and do something nasty.
[08:19] <jelmer> ah, k
[08:20] <keir> hi all
[08:21] <jelmer> 'evening keir
[08:21] <james_w> as in someone new to the plugin probably wont know about hooks, but may check debian/rules and still be surprised. I realise it's perhaps a little perverse though. I'll re-evaluate when updating the branch.
[08:21] <keir> can someone perhaps vote on my patch? http://bundlebuggy.aaronbentley.com/request/%3Cef5675f30709041204j276ce48biaa5095a939bc5749@mail.gmail.com%3E
[08:22] <keir> it's already approved by aaron, it'd be nice to get it in for .92
[08:25] <jelmer> james_w: it'd at least be nice if it was disableable
[08:25] <jelmer> on a per-user basis
[08:25] <james_w> so you enable hooks once and by doing so promise to vet all hooks from then on?
[08:27] <jelmer> yeah, something like setting '[builddeb] \ndont-authorize-hooks = True' in ~/.bazaar/bazaar.conf
[08:27] <james_w> yeah, that sounds like a good idea to me. Thanks.
[08:29] <jelmer> keir: I'll have a look later this evening if it hasn't been approved by then
[08:29] <keir> jelmer: thanks!
[08:33] <keir> is there a 'standard' way to write tests which should work for multiple implementations of the same interface?
[08:34] <keir> i'd like to factor tests which work against the GraphIndex layer such that I can use them against my own code
[08:34] <keir> then any implementation-specific tests go elsewhere
[08:39] <james_w> keir: yes there is
[08:39] <LaserJock> I've got a merging question
[08:39] <james_w> workingtree_implementations is one set.
[08:40] <LaserJock> if I've got two branches that have common parts, can I just merge the common parts
[08:41] <james_w> keir: you want adapt_modules from bzrlib/tests/__init__.py
[08:41] <keir> ok
[08:42] <james_w> keir: and bzrlib/tests/workingtree_implementations/__init__.py for an example.
[08:45] <james_w> LaserJock: can you be more clear please? They are unrelated branches that have some of the same files?
[08:45] <LaserJock> I guess they could be considered unrelated
[08:46] <LaserJock> so there's some directories that are common to both (actually several branches)
[08:47] <LaserJock> basically, can I merge just a directory in a branch or do I have to merge the whole branch
[08:50] <NfNitLoop> If they're unrelated branches, you can't use 'bzr merge'.
[08:50] <NfNitLoop> you'll probably just want to use 'patch', then commit.
[08:50] <LaserJock> hmm
[09:09] <NfNitLoop> if two projects share the same directory, though, it sounds like that directory is a library?
[09:09] <NfNitLoop> You might want to move that library into its own repo.
[09:09] <NfNitLoop> (or suggest it to the project maintainer, if that's not you.)
[09:09] <LaserJock> well, it's actually documentation
[09:09] <LaserJock> the Ubuntu Documentation project
[09:09] <LaserJock> and I'm trying to figure out how we'd handle common directories
[09:09] <LaserJock> right now we have it all in one SVN repo
[09:09] <NfNitLoop> What format is thet documentation in?  HTML?
[09:09] <LaserJock> docbook
[09:09] <NfNitLoop> ah.  Not familiar with that one.   Was wondering if you could just link to the relevant parts.
[09:09] <NfNitLoop> so you wouldn't have to maintain your own copy.
[09:09] <LaserJock> it's all our stuff
[09:09] <LaserJock> I'm wondering if we'd have to do a separate branch for the common stuff
[09:09] <LaserJock> but that's not very good because then people have to get 2 branches to get the docs
[09:34] <keir> i just co'd blender trunk, and there's now a blender/ and a lib/ directory. do i need to import those both? or can i just take the blender/ directory?
[09:37] <james_w> dato: your hookless-email seems to have died for pkg-bazaar.
[09:37] <james_w> keir: import?
[09:37] <keir> james_w, i'm setting up a parallel svn repo for a branch
[09:39] <james_w> you checked out svn or bzr? and you are setting up an svn repo?
[09:40] <keir> sv
[09:40] <keir> svn
[09:40] <keir> bzr is impractical for a couple of reasons, namely lack of a really stable windows gui
[09:40] <keir> (i don't use windows, but the students i'm working with are)
[09:41] <james_w> you checked out svn and are setting up svn? Is this really a question for #bzr?
[09:41] <keir> GAH
[09:41] <fullermd> Pshaw.  Think of it as an opportunity to enlighten them   ;p
[09:41] <keir> wrong window
[09:41] <keir> sorry
[09:41] <james_w> np
[09:50] <ubotu> New bug: #139456 in bzr "failed to open trace file: [Errno 13]  Permission denied: '/.bzr.log'" [Undecided,New]  https://launchpad.net/bugs/139456
[09:52] <dato> james_w: right. it dies on commits without a valid email address. restarted, and noted in the TODO to fix that case.
[09:55] <james_w> dato: thanks.
[10:18] <james_w> I didn't think that ExternalBase tests would give you a branch to work from when you start as a lot run init or similar first, but apparently you get a branch.
[10:18] <jelmer> lifeless: ayt?
[10:48] <lifeless> jelmer: jo?
[10:48] <lifeless> keir: you tried bzr tortoise?
[10:48] <keir> lifeless, no
[10:49] <keir> lifeless, the issue is that i have absolutely no time to debug their problems if it doesn't Just Work Every Time
[10:49] <keir> i'm certain tortoise svn is rock solid, so that's what it'll be for now
[10:49] <fullermd> My impression from looking at the tortoise and olive/win32 is that they may work well, if you make it through the install process.
[10:50] <lifeless> keir: I see
[10:50] <lifeless> thats fair enough
[10:50] <keir> lifeless, in addition i don't have time to mess with tracbzr. so svn it is
[10:51] <keir> the students are not of the 'i'll try to use it because it's oss despite some problems' types (at least as far as i can tell)
[10:51] <jelmer> lifeless: I'm hitting an assertion in Repository.add_inventory() in the packs branch
[10:51] <keir> i feel killer trac integration is important. i know launchpad should eventually be good enough, but many projects want to self-host
[10:51] <jelmer> lifeless: self.is_in_write_group()
[10:52] <jelmer> removing it doesn't seem to cause trouble
[10:53] <lifeless> keir: yah, I know some folk using tracbzr
[10:53] <lifeless> keir: tim hutch, abentley IIRC
[10:54] <lifeless> jelmer: whats the call stack when you hit that assertion? You *really* want to leave it in place and not trigger it.
[10:54] <keir> lifeless, cool, glad to see it's usable. until it's in upstream trac though, it's harder to justify.
[10:54] <jelmer> tim never did any tracbzr work afaik
[10:55] <keir> anyway: mkdir bzrlib/trac/index_implementations?
[10:55] <lifeless> jelmer: I didn't claim he was an author :)
[10:55] <jelmer> lifeless: doh, I should read better
[10:55] <lifeless> keir: well, we're using moin;
[10:55] <lifeless> jelmer: tim is a trac corish dude though
[10:55] <keir> lifeless, i'm going to separate out the tests for graphindex such that we can try different ones
[10:56] <asabil> keir: I am using bzr at work
[10:56] <jelmer> we use trac-bzr for bitlbee - http://bugs.bitlbee.org/bitlbee/
[10:56] <asabil> keir: I am a linux devel, but most people in my team are windows developers
[10:56] <keir> lifeless, moin is nice, but trac's integration is amazing. in particular, the timeline is *so* useful
[10:56] <asabil> keir: maybe you wanna try QBzr for windows
[10:56] <jelmer> lifeless: it was triggered from bzr-svn, let me see if I can find the backtrace...
[10:56] <lifeless> jelmer: then its a bug in bzr-svn for 0.90 and up; I'll help you debug it
[10:58] <keir> actually the thing i miss most from trac to launchpad is the timeline and wiki, in that order.
[10:58] <keir> the current launchpad timeline is at the appropriate granularity for typical users, but is not as useful for devs
[10:58] <jelmer> lifeless: I'm calling Repository.add_revision()
[10:59] <jelmer> but I don't use write groups at all myself
[11:00] <lifeless> jelmer: then thats the bug
[11:01] <lifeless> jelmer: you are an implementor of fetch basically, so you need to manage the write group yourself
[11:01] <jelmer> lifeless: ok, I guess that makes sense
[11:01] <jelmer> though I've never had to do so before
[11:02] <lifeless> its an API change, in NEWS
[11:02] <lifeless> locking is about mutual exclusion
[11:02] <lifeless> write groups are about transactions
[11:03] <lifeless> you want to minimise the number of transactions you do, but you could do one per rev if you want
[11:03] <lifeless> each transaction generates one pack and matching indices
[11:03] <jelmer> ahh
[11:03] <lifeless> at the end of each transaction autopack is run which will combine packs as needed to prevent linear growth
[11:04] <jelmer> and no data gets written before the write group is committed?
[11:04] <jelmer> or, at least, not necessarily?
[11:04] <lifeless> with packs data is written to .bzr/repository/upload/lock-token.tmp
[11:05] <lifeless> at commit time the pack is finished, indexed, and then its all renamed into place and finall the pack name is added to pack-names
[11:05] <lifeless> abentley: are you around ?
[11:05] <jelmer> ok, so I would want to create a new commit group every X revisions
[11:06] <lifeless> jelmer: if you expect people to abort things and want to be resumable yes
[11:06] <jelmer> so that hitting Ctrl+C halfway through fetching a 20k revision branch won't lose all data
[11:06] <jelmer> lifeless: cool, thanks
[11:10] <keir> so the XXXX_implementations/ directory actually holds blackbox tests (aka tests that only use the interface?)
[11:14] <keir> i'd probably have named them workingtree_blackbox/
[11:14] <keir> i expected the opposite (that ..._implementations/ would contain tests for specific implementations)
[11:22] <jelmer> lifeless: InventoryDirectory.snapshot() is no longer available - is that intentional?
[11:24] <lifeless> jelmer: yes
[11:25] <lifeless> keir: we may rename them to per_workingtree or something
[11:25] <lifeless> keir: but yes, the *_implementation directories yes that 'each implementation meets the interface'
[11:25] <jelmer> lifeless: it's not in NEWS
[11:25] <lifeless> jelmer: its not in bzr.dev either
[11:26] <lifeless> jelmer: look at repository.py's CommitBuilder
[11:26] <jelmer> lifeless: may not be used, but it is still available
[11:26] <lifeless> jelmer: snapshot ?
[11:27] <jelmer> yes, http://bazaar-vcs.org/bzr/bzr.dev/ still has InventoryDirectory.snapshot() in bzrlib/inventory.py
[11:27] <lifeless> jelmer: 'the patch to remove snapshot is not merged to bzr.dev'
[11:27] <lifeless> my clarity was absent
[11:27] <jelmer> ahh
[11:28] <jelmer> should I be complaining about API breakage in packs that's not in NEWS at this point?
[11:28] <jelmer> or wait until later?
[11:29] <lifeless> you're welcome to complain
[11:29] <lifeless> complaints with patches are better
[11:30] <jelmer> I feared that would be your reply..
[11:30] <lifeless> :)
[11:30] <lifeless> so snapshot is part of my commit refactoring branch
[11:30] <lifeless> I'm moving responsibility for storing entries to the CommitBuilder
[11:30] <lifeless> so it can vary between repository more cleanly
[11:31] <jelmer> so the idea is to have fetchers use CommitBuilder as well?
[11:32] <jelmer> s/so//
[11:32] <lifeless> well
[11:32] <lifeless> converters do you mean ?
[11:32] <jelmer> yeah, the generic fetchers
[11:32] <lifeless> it would be nice if we *had* generic fetchers
[11:32] <lifeless> right now the most generic is still very versioned file centric
[11:33] <keir> pdb is so slooooooow. is there a way to say 'don't load pdb, unless an exception is thrown'?
[11:33] <keir> for the selftests?
[11:34] <lifeless> but yes, using CommitBuilder is the right thing to do if all you have is a tree shape and need to store a representation of that from first principles
[11:34] <lifeless> however, doing targeted converters is the way to better performance
[11:34] <lifeless> keir: hmm, are you running under pdb ?
[11:34] <jelmer> lifeless: I may be interested in writing a generic fetcher if I want to try out packs + bzr-svn
[11:35] <jelmer> since bzr-svn's fetcher is very VersionedFile-centric atm
[11:35] <lifeless> jelmer: your current knit converter should work (unless you were using inventory.snapshot)
[11:35] <jelmer> I /am/ using Inventory.snapshot :-)
[11:36] <lifeless> heh
[11:36] <lifeless> ok, well I'm trying to land this change in 0.92
[11:36] <keir> lifeless, pdb ./bzr selftest ...; however, it's useless because the testing framework is catching the exception
[11:36] <lifeless> I'm also overhauling commit builder for more strict separation between repository and tree
[11:36] <lifeless> keir: eek.
[11:36] <lifeless> we should enable the debug option
[11:37] <lifeless> which unittest has but we don't present. anyway -
[11:37] <lifeless> I do import pdb;pdb.set_trace() in the test that fails
[11:37] <lifeless> then ./bzr selftest failingtestname
[11:37] <keir> lifeless, but it only fails in one specific case
[11:38] <keir> lifeless, sorry, that wasn't clear
[11:38] <lifeless> keir: so only run that test :)
[11:38] <keir> yeah, ok
[11:39] <keir> sorry. set_trace() launches a debugger where you put the set_trace()
[11:39] <keir> i don't want that
[11:39] <lifeless> because ... ?
[11:39] <keir> i want a debugger exactly where the exception is thrown, which is way down past a bunch of iterations of the search
[11:40] <lifeless> ok
[11:40] <lifeless> sometimes its whack
[11:40] <lifeless> but you can do
[11:40] <lifeless> try:
[11:40] <lifeless>     thing
[11:40] <lifeless> except:
[11:40] <keir> aah right
[11:40] <lifeless>     pdb.pm()
[11:40] <keir> nasty
[11:41] <lifeless> not really nasty, its what BZR_PDB=1 does for non-test-suite code
[11:41] <keir> i see
[11:44] <lifeless> but pscyo IIRC really breaks it
[11:50] <ubotu> New bug: #139478 in bzr "bzr: ERROR: bzrlib.errors.UnlockableTransport" [Undecided,New]  https://launchpad.net/bugs/139478
[12:01] <james_w> hmm, it's odd that came from an update isn't it?