[00:06] <dysinger> jelmer so I updated the wiki again with details
[00:06] <dysinger> it _almost_ works on leopard - just not if you want svn+ssl
[00:36] <Verterok> moin
[00:37] <jelmer> re
[00:38] <jelmer> dysinger: ok, that's not a bzr backtrace but a python-subversion one
[00:38] <dysinger> hmmm
[00:38] <dysinger> ok
[00:38] <jelmer> dysinger: does "bzr branch" work with https:// ?
[00:38] <dysinger> one sec
[00:39] <dysinger> no same error on ssl
[00:40] <dysinger> I wonder why it works with non-ssl and python-subversion
[00:42] <jelmer> it looks like it may be a bug in the python bindings for the function that asks whether you would like to accept a specific SSL certificate
[00:44] <dysinger> strange.  I already accepted the cert permanently earlier using straight svn
[00:47] <jelmer> this function gets called before svn itself I think
[00:56] <jelmer> dysinger: you may want to try commenting out line 54 of transport.py
[00:57] <dysinger> sure
[00:57] <dysinger> in svn ?
[00:57] <dysinger> oh ok in bzr-svn
[01:01] <dysinger> bummer http://pastie.caboo.se/141749
[01:01] <dysinger> now it looks like libsvn_diff ???
[01:02] <dysinger> it's calling libsvn_ra_local too
[01:02] <dysinger> that's for a file:/// scheme
[01:03] <dysinger> oh nevermind
[01:03] <dysinger> I am reading too much into the stack without knowing python.
[01:05] <jelmer> dysinger: are you sure line 52 is commented out?
[01:05] <jelmer> sorry, 54
[01:05] <dysinger> you said 54
[01:05] <dysinger> y 54 #        svn.client.get_ssl_server_trust_file_provider(pool),
[01:06] <jelmer> whoops
[01:06] <jelmer> can you enable line 54 again and comment out 46 and 47?
[01:06] <dysinger> the providers += lines ?
[01:10] <dysinger> woot it is working.... :8
[01:11]  * dysinger crosses fingers
[01:11] <jelmer> ok, looks like it's time to file a bug in the subversion bug tracker
[01:13] <dysinger> woot at least it works.
[01:14] <dysinger> I'll just keep installing bzr-svn stable and svn 1.5 trunk from scratch until it's fixed.
[01:21] <dysinger> it worked
[01:43] <Verterok> igc, poolie: hi
[01:43] <Verterok> reading the irclogs I recently found guillaumebokiau problems with the 10.4 dmg (ppc)
[01:45] <Verterok> I'm trying to build it as universal, but I can't test it because I don't have a intel mac
[01:47] <igc> hi Verterok
[01:47] <igc> I can help with that
[01:48] <Verterok> great! :D
[01:48] <igc> I'm happy to test it on 10.4 on Intel on my laptop
[01:48] <Verterok> do you have the developer tools installed?
[01:49] <igc> hmm - not sure
[01:49] <igc> I do have MacPorts installed from memory so that means yes?
[01:49] <Verterok> let me check
[01:50] <igc> and make and gcc both exist on my path fwiwi
[01:50] <Verterok> http://www.macports.org/install.php says you should
[01:50] <Verterok> maybe you can build it as universal, it's pretty easy using my scripts ;)
[01:51] <igc> sure
[01:51] <igc> where do I start?
[01:51] <Verterok> if you have time to do it, of course :)
[01:51] <igc> I can fit it in :-)
[01:51] <Verterok> bzr branch http://freeshells.ch/~guillo/code/bundle-10.4/
[01:52] <Verterok> and follow the building instructions ;)
[01:53] <Verterok> the versions I'm using for the build are: bzr == 1.1, bzr-rebase == 0.3, bzrtools == 1.1.0, pycrypto == 2.0.1, paramiko == 1.7.1 and bzr-email == trunk
[01:54] <igc> ok, I have the branch
[01:54] <igc> I'll ping you if I have any questions
[01:55] <Verterok> thanks a lot!
[02:02] <poolie> Verterok, cool, thanks!
[02:02] <poolie> igc, spiv, please work out about your trip...
[02:03] <Verterok> poolie: happy to help, and write some python (instead of java) :D
[02:04] <spiv> poolie: chatting now :)
[02:04]  * poolie stops nagging
[02:47]  * igc lunch - back later
[03:00] <GoClick> Is there an official way to voice your support for something? I would REALLY appreciate a more complete textmate integration bundle for bazaar.
[03:01] <GoClick> But I'm not programmer enough to assist with the project
[03:02] <AfC> Verterok: bzr-eclipse is using the XML plugin, right?
[03:03] <AfC> (asking only because https://blueprints.launchpad.net/bzr-eclipse/+spec/bazaar-java-client is kinda vague about it)
[03:03] <Verterok> AfC: yes
[03:04]  * AfC tries to find that.
[03:04] <Verterok> actually the java lib under the hood is usingt it
[03:05] <Verterok> AfC: you are right, I need to write a wiki page about this and link to the blueprint
[03:06] <Verterok> Also, if you have any question, I'ld be pleased to answer
[03:08]  * AfC has been studying Eclipse's platform. I've seen some crazy code bases in the past, but yikes.
[03:09] <AfC> Nutso project of the week: Java editing in vi using Eclipse as a back-end http://eclim.sourceforge.net/
[03:11] <Verterok> I look at it some time ago, it start a headless eclipse...who said vim is a lightweight editor? :)
[03:12] <AfC> I've been trying to figure out how much of Eclipse can be used headless. It would seem "quite a lot"
[03:13] <Verterok> I suppose all non-ui plugins
[03:13] <AfC> ... the Anjuta guys want to add Java functionality; my suggestion to them was to see if they could hook into Eclipse for the introspection they'd need.
[03:14] <AfC> Verterok: yeah. The question is are things like code-completion and hierarchy & outline abstracted out, or buried in the UI code.
[03:14] <AfC> Anyway, off topic for this channel, sorry. I thought I'd have another poke at bzr-eclipse to see what I could learn by comparison.
[03:15] <Verterok> private?
[03:15] <AfC> Go ahead
[03:15]  * AfC is getting ready to go out for coffee
[04:12] <minghua> Is there a way to delete a versioned directory from a tree, and claim "don't touch this directory ever again", so that future merges won't generate conflicts regarding this directory?
[04:13] <minghua> What I'm doing is complete rewriting a part of a project (the debian/ directory), while upstream is still making changes to that part occasionally.
[04:16] <poolie> minghua, i think the cleanest way would be to rename theirs to eg debian.upstream
[04:16] <poolie> and then make a new directory for yours
[04:18] <minghua> Ah, so renaming is better than deleting, makes sense.
[04:18] <minghua> poolie: Will try that, thanks!
[04:24] <poolie> you're welcome!
[04:25] <poolie> bzr rename support ftw :)
[04:41] <igc> Verterok: looks like I'm missing some stuff (like setuptools). I want to wrap up some other work first so I'll have another go later today or tomorrow.
[04:42] <Verterok> oh, I missed that :P
[04:43] <Verterok> igc: thanks again!
[04:43] <Verterok> I'm trying to fix my Xcode installation, it seems that 2.5 kill my libtool :(
[04:46] <Verterok> igc: for building the mpkg, the deps are: setuptools == dev, py2app >= 0.3.6, bdist_mpkg >= 0.4.3. easy_install install all other dependecies.
[04:47]  * Verterok heading to bed...
[04:48] <Verterok> seeya!
[04:49] <igc> seeya
[08:56] <robsta> hi
[08:57] <robsta> is it possible to migrate a project from one svn repo to another, using bzr-svn?
[08:58] <TFKyle> robsta: I think tailor (http://wiki.darcs.net/index.html/Tailor ) would be a better fit for doing that, no idea how easy it'd be with bzr-svn though
[08:59] <robsta> TFKyle: does tailor work without file-system access?
[09:00] <TFKyle> robsta: yep
[09:00] <TFKyle> (actually, if the server is subversion 1.4 or newer I think there's svnsync or something similar that does that)
[09:01] <TFKyle> (more efficiently than tailor or bzr-svn I believe)
[09:01] <robsta> looks like i'm asking the right people :)
[09:02] <robsta> will check it out
[09:06] <TFKyle> hmm, on the other hand: "You should not commit to, or make revision property changes in, the destination repository by any method other than 'svnsync'. In other words, the destination repository should be a read-only mirror of the source repository." in svnsync help init, not sure why though, might be reasonable to if you don't need to sync anymore afterwards
[09:07] <AfC> robsta: bzr-svn is very powerful, but keep in mind that any non-native tool doing a transformation will always bear the risk of being lossy in some manner.
[09:07] <AfC> tailor also counts as a non-native tool in this regard.
[09:07] <AfC> robsta: can't you just `svn_dump` or `svnadmin dump` or some such?
[09:08] <robsta> AfC: doesn't that require file-system access?
[09:08] <robsta> well, on the source machine i have it
[09:08] <AfC> robsta: (sorry, yes it does. I was making an assumption)
[09:12] <robsta> svnsync wants special hooks set, can i do that via DAV?
[09:12]  * igc night all
[09:30] <Peng> Why not take this opportunity to switch to bzr? :)
[09:33] <AfC> Peng: good show
[09:40] <robsta> because garage.maemo doesn't support it
[10:56] <yacc> Just wondering, can one host a complete project on launchpad? (Basically, do I need a sourceforge project first, or can I just host it on launchpad?)
[10:59] <TFKyle> yacc: yep (well, partially - lp doesn't do web hosting apart from what launchpad provides itself)
[11:02] <yacc> TFKyle: Well, that shouldn't be the biggest issue here ;)
[11:03] <yacc> Ok, now I just need to refactor that pile of dung, so that my face does not flash red when thinking about publishing the code :)
[11:30] <awilkins> Anyone want to talk about nested tree support?
[11:32] <lifeless> LarstiQ: ping ^
[11:38] <awilkins> Incidentally, are the Pyrex extensions used on Windows?
[11:47] <lifeless> sure
[11:49] <awilkins> Yeah, I just spent those 9 minutes installing Pyrex / MinGW and find out the .pyd files are there already :-)
[11:50] <awilkins> Ah well, at least if I use a dev branch it'll run fast....
[11:50] <lifeless> ;)
[12:01] <lifeless> hi thumper
[12:01] <thumper> lifeless: hi
[12:01] <thumper> lifeless: how goes London?
[12:02] <lifeless> cool
[13:35] <jelmer> are there any functions for parsing "bugs" revision properties yet?
[13:40] <lifeless> not sure
[13:40] <ubotu> New bug: #185072 in bzr "checkout MemoryError" [Undecided,New] https://launchpad.net/bugs/185072
[13:41]  * jelmer is trying to spend 5 spare minutes implementing a "bugs" tab in bzr viz
[13:41] <lifeless> cool
[13:41] <lifeless> how is larstiq these days?
[13:42] <AfC> heh. I just spent "5 minutes" on something. 5 hours later...
[13:43] <awilkins> Yeah, it always happens when you have a deadline for something else too
[13:44] <awilkins> "Oh, if I spend 5 minutes implementing foo, it'll make doing bar a lot faster..."
[13:44] <AfC> Well I have a deadline for sleep. See ya
[13:45]  * awilkins slurps coffee
[13:45] <awilkins> I may take a nap though, wifey kept me up snoring all night
[13:51] <jelmer> lifeless: he's back on IRC but a bit busy with other things afaik
[14:33] <jelmer> ok, little bit more than 5 minutes :-)
[14:33] <jelmer> http://samba.org/~jelmer/bzr/bzr-gtk-bugs.png
[14:36] <jelmer> hmm, likewise it should be possible to select the bug you've fixed using gcommit
[14:36] <jelmer> lifeless: There doesn't happen to be some pygtk app that allows browsing launchpad bugs ?
[14:37] <lifeless> there is bughelper, which is cli
[14:38] <jelmer> ah, ok
[14:39] <mtaylor> NoSuchRevision: KnitRevisionStore(VersionedFileStore('file:///home/mtaylor/src/ndb-connectors/.bzr/repository/')) has no revision mtaylor@mysql.com-20080120230546-5k2iof52169dzz7x
[14:39] <mtaylor> I was trying to do a bzr diff
[14:41] <ubotu> New bug: #185086 in bzr "No easy way to access "bugs" revision property" [Wishlist,Triaged] https://launchpad.net/bugs/185086
[14:41] <jelmer> mtaylor: Is this a repository originally imported from svn?
[14:41] <mtaylor> jelmer: nope
[14:41] <mtaylor> jelmer: this is a pure bzr repos
[14:42] <mtaylor> so I also now get this, when I try to branch that branch to somewhere else:
[14:42] <mtaylor> bzr branch devel develnew
[14:42] <mtaylor> bzr: ERROR: The branch devel has no revision None.
[14:42] <jelmer> mtaylor: which repository format?
[14:43] <mtaylor> Shared repository with trees (format: dirstate or dirstate-tags or knit)
[14:43] <lifeless> mtaylor: can you do a bzr check ?
[14:44] <mtaylor> bzr check
[14:44] <mtaylor> bzr: ERROR: Revision {mtaylor@mysql.com-20080120230546-5k2iof52169dzz7x} not present in "revisions".
[14:44] <lifeless> do you use NFS ?
[14:44] <mtaylor> nope. this is on my laptop
[14:44] <mtaylor> xfs
[14:44] <lifeless> ok, bizarre
[14:44] <lifeless> so here is what bzr hinks is going on
[14:44] <mtaylor> this is not the first time this has happened to me
[14:44] <lifeless> .bzr/repository/revisions.kndx does not list mtaylor...zz7x
[14:45] <mtaylor> ok
[14:45] <lifeless> but .bzr/branch/* does
[14:45] <lifeless> are you using rsync to move data around or anything like that?
[14:45] <mtaylor> nope. just normal bzr
[14:45] <lifeless> if this is happening repeatedly, something is causing it not cosmic rays :)
[14:45] <lifeless> you don't use 'rspush' ?
[14:46] <mtaylor> nope. just push and pull and branch over bzr+ssh
[14:46] <lifeless> was this revision the same one that the problem occured in before?
[14:46] <lifeless> and are you able to upgrade to packs :)
[14:46] <lifeless> the only likely thing I can think of is:
[14:47] <mtaylor> I can certainly try  - but no, the last time this happened I just created a new repos, branched from pushed branches and manually added the diffs back
[14:47] <jelmer> mtaylor: have you run xfs_fsr recently?
[14:48] <mtaylor> jelmer: no. should I?
[14:48] <jelmer> mtaylor: no, but apparently that could be a cause for corruption
[14:48] <mtaylor> ah.
[14:48] <jelmer> I see another report on the mailing list about corruption on XFS
[14:49] <mtaylor> I did have my laptop power off due to battery death on the plane the other day
[14:49] <jelmer> https://lists.ubuntu.com/archives/bazaar/2007q3/029036.html
[14:49] <mtaylor> I would be very sad if that caused something to not be written to disk
[14:52] <jelmer> It seems somewhat likely to me this is related to XFS since it's not that commonly used and I can't recall any corruption reports in the last year except from the one I just linked to
[14:52] <jelmer> that may be a somewhat premature conclusion, though
[14:52] <mtaylor> yeah.
[14:52] <mtaylor> would it be helpful at all for me to tar up my repo and send it to someone?
[15:01] <mtaylor> lifeless: should I be using packs for everything now?
[15:15] <mtaylor> so, now I'm also getting this:
[15:15] <mtaylor> AttributeError: 'NoneType' object has no attribute 'as_dict
[15:15] <mtaylor> when I try to pull
[15:15] <mtaylor> it seems to be in:
[15:15] <mtaylor>  File "/usr/lib/python2.5/site-packages/bzrlib/lockdir.py", line 445, in _parse_info
[15:15] <mtaylor>     return read_stanza(info_file.readlines()).as_dict()
[15:22] <mtaylor> lifeless: would a copy of my repos be helpful? it's a public project
[15:35] <ubotu> New bug: #185095 in bzr-gtk "gcommit should provide ability to mark bugs as fixed" [Wishlist,Triaged] https://launchpad.net/bugs/185095
[15:38] <lifeless> hi mtaylor sorry I was distracted by the boss :)
[15:38] <mtaylor> lifeless: darn bosses
[15:38] <lifeless> mtaylor: yes, packsa re good kthxbye
[15:38] <mtaylor> :)
[15:38] <lifeless> so your bug the only ting I can think of is:
[15:39] <lifeless> append(revisions.knit)
[15:39] <lifeless> append(revisions.kndx)
[15:39] <lifeless> write(branch_data)
[15:39] <lifeless> poweroff -> branch_data committed, revisions.knit not
[15:39] <mtaylor> ahhh
[15:39] <lifeless> AIUI xfs is very much against writing data to disk
[15:40]  * mtaylor . o O ( 2pc between branch_data and revisions.knit )
[15:40] <mtaylor> lifeless: that sounds reasonable
[15:41] <mtaylor> lifeless: anyway you can think of to recover from this?
[15:45] <lifeless> uhm
[15:47] <CardinalFang> Custom tiny script to roll back that one change?
[15:51] <lifeless> mtaylor: what format branch is it ? (bzr info -v and look for Branch Format)
[15:52] <mtaylor> lifeless: that gives me a traceback
[15:52] <mtaylor>   File "/usr/lib/python2.5/site-packages/bzrlib/lockdir.py", line 445, in _parse_info
[15:52] <mtaylor>     return read_stanza(info_file.readlines()).as_dict()
[15:52] <mtaylor> AttributeError: 'NoneType' object has no attribute 'as_dict'
[15:52] <lifeless> less .bzr/branch/format
[15:52] <mtaylor> Bazaar Branch Format 6 (bzr 0.15)
[15:52] <lifeless> oh!
[15:53] <lifeless> ls .bzr/branch/lock
[15:53] <lifeless> and .bzr/repository/lock
[15:53] <lifeless> we have at least one latent bug here
[15:53] <mtaylor> mtaylor@solace:~/src/ndb-connectors-borked/devel$ ls .bzr/branch/lock/
[15:53] <mtaylor> held
[15:53] <mtaylor> mtaylor@solace:~/src/ndb-connectors-borked/devel$ ls ../.bzr/repository/lock/
[15:53] <mtaylor> held
[15:53] <lifeless> ok, ls in the held dir too ?
[15:53] <mtaylor> info
[15:54] <lifeless> in both ?
[15:54] <mtaylor> yes
[15:54] <lifeless> ok, can you please file a bug about that backtrace
[15:54] <mtaylor> yes.
[15:54] <lifeless> you can get the whole trace from .bzr.log
[15:54] <lifeless> separately
[15:54] <mtaylor> which one?
[15:54] <mtaylor> is this the bzr info -v produces a backtrace ?
[15:54] <lifeless> bzr info -v failing
[15:54] <mtaylor> ok
[15:54] <lifeless> now, bzr thinks that this tree is locked
[15:55] <mtaylor> oh
[15:55] <mtaylor> well that's silly
[15:55] <lifeless> its consistent with a poweroff failure and changes not being flushed to disk
[15:55] <lifeless> bzr break-lock
[15:55] <mtaylor>     return read_stanza(info_file.readlines()).as_dict()
[15:55] <mtaylor> AttributeError: 'NoneType' object has no attribute 'as_dict'
[15:56] <lifeless> should let you break them; if it doesn't (and it may not as the info -v failure is indicative of a problem) we will brek them by hand
[15:56] <lifeless> rm the 'held' directories. That will let us start mutating the tree
[15:56] <lifeless> now, we need to figure out the most recent commit
[15:56] <lifeless> install the 'heads' plugin
[15:57] <lifeless> (most recent commit that has been committed :)
[15:57] <lifeless> we'll want to work on a copy of the tree not the tree itself.
[15:57] <mtaylor> ok
[15:57] <mtaylor> copy of the branch or copy of the whole repos?
[15:58] <mtaylor> oh. nm... I've got a backup, I just tarred it up a second ago
[15:59] <lifeless> k
[15:59] <lifeless> now
[15:59] <mtaylor> looking for heads plugin
[16:00] <mtaylor> k gotit
[16:00] <dennda> is it me or is the latest bzr you can get from your repo much faster than the one in ubuntus repos?
[16:00] <mtaylor> dennda: the one in ubuntu is old
[16:00] <mtaylor> dennda: it's not just you
[16:01] <dennda> boy that is good news!
[16:02] <mtaylor> lifeless: ok. I' ve done all of that
[16:03] <mtaylor> lifeless: heads doesn't show my devel branch at all
[16:03] <lifeless> I think you --all
[16:03] <lifeless> *need*
[16:03] <mtaylor> yup
[16:03] <lifeless> now find a rev id you want to use
[16:04] <lifeless> init a new branch (can be in the same repo if you like)
[16:04] <lifeless> bzr pull -r revid:REVID ../oldbranch in the new branch
[16:04] <lifeless> this will give you a healthy branch, and we need to just recover your most recent commit
[16:04] <mtaylor> lifeless: it shows two entires for branch "devel"
[16:04] <mtaylor> both of them show as (dead) revisions
[16:04] <lifeless> thats because the graph is incomplete
[16:05] <mtaylor> ok
[16:05] <lifeless> are they both yours?
[16:05] <mtaylor> yes
[16:05] <mtaylor> and one of them is the one I would want
[16:05] <lifeless> good
[16:05] <lifeless> thne do the above
[16:05] <mtaylor> bzr: ERROR: Revision {mtaylor@mysql.com-20080120230546-5k2iof52169dzz7x} not present in "revisions".
[16:05] <ubotu> New bug: #185103 in bzr "bzr info -v produces a traceback" [Undecided,New] https://launchpad.net/bugs/185103
[16:06] <lifeless> that was in heads ?
[16:06] <mtaylor> yes
[16:06] <lifeless> hrm
[16:06] <mtaylor> but was listed as dead
[16:07] <lifeless> ok, lets try a different approach
[16:07] <lifeless> :q
[16:07]  * mtaylor is having fun with bzr today!!!
[16:07] <lifeless> python
[16:07] <lifeless> import bzrlib.repository
[16:08] <lifeless> r = bzrlib.repository.Repository.open('.')
[16:08] <lifeless> r.lock_read()
[16:08] <lifeless> heads =  r.get_graph().heads(r.all_revision_ids())
[16:08] <mtaylor> bzrlib.errors.NoRepositoryPresent: No repository present: "file:///home/mtaylor/src/ndb-connectors-borked/devel/"
[16:08] <lifeless> use .. then :)
[16:08] <mtaylor> oh, right
[16:08] <mtaylor> du
[16:09] <mtaylor> ok. I have a heads set
[16:09] <lifeless> mtaylor: how big is it, and is ...7x in it ?
[16:10] <mtaylor> lifeless: there are 7 elements, and no, ...7x is not there
[16:11] <lifeless> good :)
[16:11] <lifeless> ok, we can look at each commit with:
[16:11] <lifeless> print r.get_revision(revid).message
[16:11] <lifeless> one of the elements should be the previous commit on the damaged branch
[16:12] <mtaylor> yes. there it is
[16:12] <mtaylor> mtaylor@mysql.com-20080120223107-b1c4f5d4bez3g38h
[16:13] <lifeless> ok, init another branch, pull that revid into it with the instructions from above
[16:14] <mtaylor> I'm still getting the bzr: ERROR: Revision {mtaylor@mysql.com-20080120230546-5k2iof52169dzz7x} not present in "revisions".
[16:15] <lifeless> ok
[16:16] <lifeless> echo '0 null:' > .bzr/branch/last-revision
[16:16] <lifeless> then try
[16:19] <fullermd> If you do it in the same repo, couldn't you just 'pull -rfoo .', and save possibilities of getting confused by the b0rked branch?
[16:20] <lifeless> fullermd: yah
[16:22] <mtaylor> ok. I tried pull -rfoo .
[16:22] <mtaylor> and I got: bzr: ERROR: Revision {mtaylor@mysql.com-20080120222208-5vy3xpyzb0pl7lcj} not present in "44/configure.in-20070228020914-u2pk759xg7thauwf-13.kndx".
[16:27] <mtaylor> and I tried echo '0 null:' > .bzr/branch/last-revision
[16:28] <mtaylor> in the new branch and then pulling and that didn't work
[16:28] <mtaylor> should I try echo '0 null:' > .bzr/branch/last-revision in the devel branch?
[16:29] <jrydberg_> jelmer: if i use bzr-svn, do i get merge tracking? :)
[16:30] <jelmer> jrydberg_: Yes
[16:31] <jrydberg_> jelmer: how do you do that?
[16:31] <jelmer> jrydberg_: bzr-svn stores the non-lhs parents in a svn property
[16:32] <jelmer> well, not the parents itself but the parent revids
[16:32] <jrydberg_> jelmer: cool.  do i still have to patch the python bindings?
[16:32] <jelmer> jrydberg_: yes, unless you are on Debian Sid/Lenny or Ubuntu >= gutsy
[16:37] <lifeless> mtaylor: I'm smeelling more and more data issues here
[16:37] <lifeless> mtaylor: is the copy on launchpad healthy ?
[16:37] <mtaylor> lifeless: yeah - I'm repulling that right now
[16:37] <mtaylor> lifeless: you think just use that an apply individual changes by hand?
[16:37] <lifeless> mtaylor: also, *really* move to packs: the non-append nature of that makes it much more robust against silly file systems (though not imune)
[16:38] <lifeless> I think use that and copy your working tree over the top
[16:38] <mtaylor> lifeless: ok. do I need to do anything to upgrade my lp repos?
[16:38] <lifeless> bzr upgrade sftp://bazaar.launchpad.net ..../
[16:38] <lifeless> sftp is important
[16:49] <mtaylor> for the upgrade?
[16:49] <mtaylor> oh, because lp doesn't have recent bzr
[17:18] <lifeless> mtaylor: no, because bzr+ssh doesn't have an upgrade verb today :)
[17:50] <LarstiQ> lifeless: 'meh' sums it up currently
[17:50] <LarstiQ> awilkins: you wanted to talk?
[17:53] <guillaumebokiau> Unable to obtain lock .bzr/checkout/lock
[17:53] <guillaumebokiau> what now ?
[17:54] <guillaumebokiau> I restarted the computer to no luck.
[17:54] <guillaumebokiau> I deleted /held/ to no luck
[17:55] <awilkins> LarstiQ: I was wondering how the nested trees were doing :-)
[17:55] <jelmer> does "bzr break-lock" help?
[17:56] <guillaumebokiau> ah, yes, thx
[17:56] <LarstiQ> awilkins: at least from my side, not a lot of movement lately. But got an offer to tests on some reallife machines, so I'll be wanting to get back at it. Have to spend time in airports tomorrow, we'll see.
[17:57] <guillaumebokiau> but when i commit now i get this :
[17:57] <LarstiQ> awilkins: so the status is roughly, they exist but don't try to do too much with it if you're not willing to deal with breaking
[17:57] <awilkins> LarstiQ: Ah, ok, I have some reasonably substantial VB6 projects with lots of use-of-common-library-but-not-linked-compiled-in
[17:57] <guillaumebokiau> Committing to: /Users/guillaumebokiau/Sites/xpattern-1.0/
[17:57] <guillaumebokiau> modified textpattern/lib/txplib_parse.php
[17:57] <guillaumebokiau> -------------- This line and the following will be ignored --------------
[17:57] <guillaumebokiau> modified:
[17:57] <guillaumebokiau>   textpattern/lib/txplib_parse.php
[17:57] <guillaumebokiau> unknown:
[17:57] <guillaumebokiau>   bzr_log._4LcnW
[17:57] <guillaumebokiau>   css/articles.css
[17:57] <guillaumebokiau>   css/default.css
[17:57] <awilkins> LarstiQ: So more testing material :-)
[17:57] <guillaumebokiau>   textpattern/.DS_Store
[17:57] <guillaumebokiau>   textpattern/config.php
[17:57] <guillaumebokiau>   textpattern/publish/newtaghandlers.php
[17:57] <guillaumebokiau> ~
[17:57] <guillaumebokiau> ~
[17:57] <guillaumebokiau> ~
[17:57] <guillaumebokiau> ~
[17:58] <guillaumebokiau> ~
[17:58] <guillaumebokiau> ~
[17:58] <LarstiQ> guillaumebokiau: woha, easy there
[17:58] <guillaumebokiau> ~
[17:58] <guillaumebokiau> ~
[17:58] <luks> eek
[17:58] <guillaumebokiau> ~
[17:58] <guillaumebokiau> ~
[17:58] <guillaumebokiau> "bzr_log.Q_aXL4" 13L, 275C
[17:58] <guillaumebokiau> and it freezes or sthg
[17:58] <guillaumebokiau> sorry for your ears :)
[17:58] <LarstiQ> guillaumebokiau: please use a paste service if you got more than a few lines to show
[17:58] <awilkins> You're lucky this channel doesn't kick for excess flood
[17:58] <LarstiQ> awilkins: good, good :)
[17:58] <LarstiQ> awilkins: does code move across those subtree boundaries often?
[17:59] <guillaumebokiau> will do
[17:59] <awilkins> LarstiQ: I think the commonest case is where I patch the library a bit and want some of the changes but not all pushed to the main branch
[18:00] <awilkins> LarstiQ: Or maybe all
[18:00] <LarstiQ> ah, ok
[18:00] <awilkins> I've tried both common approaches - svn:externals and svn cp
[18:01] <LarstiQ> awilkins: you're using svn as a backend?
[18:01] <awilkins> awilkins: I'm using svn as my production VCS at present
[18:01] <LarstiQ> and you'd want to keep it that way?
[18:02] <awilkins> LarstiQ: I'm experimening with bzr because some of the things I'm having to do are very slow now
[18:02] <awilkins> LarstiQ: The big one is this project where I'm having to do a lot of merging - in an automated manner, with possible trunk > branch merges followed by branch > trunk merges
[18:03] <LarstiQ> ok
[18:03] <awilkins> LarstiQ: No nested trees in that one though, but I'm shuddering at writing it for svn ; the problem is it's for an Eclipse application and the bzr-eclipse plugin is rather ... green
[18:04] <awilkins> I might actually want to leverage bzr anyway to make the branch management easier
[18:06] <LarstiQ> hey Zindar
[18:06] <guillaumebokiau> anyone available to help me with the problem?
[18:06] <LarstiQ> awilkins: how early in the process would you feel comfortable testing stuff out?
[18:06] <beuno> awilkins, you can file bugs for any bzr-eclipse features you'd like. The developer is fairly active, he just needs stuff to do  ;)
[18:07] <LarstiQ> guillaumebokiau: when does it freeze? Did you write a commit entry and save it?
[18:08] <guillaumebokiau> yes, a couple
[18:08] <awilkins> LarstiQ: I can find some time to set up a bzr repo and import some branches into it for my projects and the common library, and trty nesting it.
[18:08] <guillaumebokiau> It seems I can uncommit though.
[18:08] <guillaumebokiau> would that help : uncommiting the last commit?
[18:08] <LarstiQ> awilkins: cool. I'll ping you when I have a current branch then.
[18:09] <LarstiQ> guillaumebokiau: why would you do that?
[18:09] <guillaumebokiau> In case it was the last commit that caused a problem
[18:09] <awilkins> LarstiQ: I tried to branch it from launchpad but I got no joy, soes it need an upgrade or somehitng?
[18:09] <guillaumebokiau> but no, that doesn't seem to solve it.
[18:09] <LarstiQ> guillaumebokiau: I'm confused as to what your problem is, could you explain it once more please?
[18:09] <awilkins> LarstiQ: I think I filed a bug for that
[18:10] <LarstiQ> awilkins: what did you try to branch?
[18:10] <awilkins> bzr-svn
[18:10] <guillaumebokiau> I try commiting. It then does that error code I posted above
[18:10] <guillaumebokiau> and creates a log
[18:10] <guillaumebokiau> well, i don't even know if it is an error code
[18:10] <LarstiQ> awilkins: be sure to name the resulting branch something like 'svn', that is, don't leave the - in the plugin name or it will not be seen as a valid plugin.
[18:11] <awilkins> LarstiQ: Ah, the replay branch, sorry
[18:11] <LarstiQ> guillaumebokiau: what exact error?
[18:11] <LarstiQ> awilkins: now you're out of my league and into jelmer's, I don't know that much about bzr-svn :)
[18:11] <awilkins> LarstiQ: Nothing to do with nested trees
[18:12] <LarstiQ> awilkins: not directly at least, it may be a consumer of them
[18:12] <awilkins> LarstiQ: That would be a potential use case, since I have the source in an SVN repo at present
[18:12] <lifeless> guillaumebokiau: can you comit if you do 'bzr commit -m " message here" ' ?
[18:13] <guillaumebokiau> ah, maybe i forgot the message
[18:13] <guillaumebokiau> will try
[18:13] <awilkins> LarstiQ: And no immediate chance of changing that ; this is a government dept. and I only just managaed to convert them to SVN 2 years ago (from the "bung it on a shared drive and pray" method)
[18:14] <guillaumebokiau> ok, that was it. stupid me
[18:14] <awilkins> LarstiQ: For reference, they had been considering either CVS or Visual SourceSafe for 6 months....
[18:14] <guillaumebokiau> thanks lifeless and LarstiQ
[18:15] <LarstiQ> awilkins: ah yes, the government is always fun :)
[18:15] <LarstiQ> guillaumebokiau: np
[18:17]  * LarstiQ goes afk for a while
[18:45] <jelmer> awilkins: there is no reason to be using the replay branch at the moment
[18:45] <jelmer> it's still a work in progress and doesn't provide any advantages over using the 0.4 branch
[18:47] <awilkins> jelmer: Is improved speed not an advantage?
[18:47] <awilkins> jelmer: Particularly since (AFAIK) it doesn't support a horizon.
[18:47] <jelmer> awilkins: the replay branch is a work in progress, it's not finished yet
[18:47] <jelmer> awilkins: it doesn't provide any advantages yet
[18:47] <awilkins> jelmer: Yes, fair enough, I wasn't expecting to use it in production, I just wanted to look at the source
[18:48] <awilkins> jelmer: Working replay would be a major plus point for bzr over the likes of SVK, which has replay but it doesn't work on Win32
[18:49] <jelmer> awilkins: replay != history horizon
[18:49] <awilkins> jelmer: It makes a lot of difference on larger trees
[18:49] <jelmer> awilkins: or is the advantage of using svn_ra_replay() over a bunch of svn_ra_update() calls really that big?
[18:50] <awilkins> jelmer: Yes, replay is not horizon, but without horizon, taking the full history of an SVN branch is a very prolonged task without replay
[18:50] <awilkins> jelmer: SVK has enormous CPU demands even on fairly small trees (a few thousand XML files)
[18:51] <awilkins> And that's perl, it's supposed to be astounding at that sort of thing
[18:51] <jelmer> awilkins: what makes replay so fast then? afaik the only thing you save is 1 roundtrip per revision
[18:52] <awilkins> awilkins: I'm going to have to measure it now, aren't I :-)
[18:52] <xif> So what's the deal with keyword substitution implementation in bzr?
[18:52] <jelmer> xif: there is none
[18:52] <xif> the best I could find was this brain-dump: http://bazaar-vcs.org/KeywordExpansion
[18:52] <jelmer> xif: there is a specification, but nobody is working on implementing it at the moment
[18:52] <jelmer> yep, that's the one
[18:53] <xif> jelmer: hm, sucks, why not?
[18:53] <xif> surely you bzrers can see how useful it would be!
[18:53] <xif> can I write it in Python?
[18:53] <jelmer> xif: yes, but there's other important things as well...
[18:53] <awilkins> jelmer: svnsync uses replay and it's very quick ; SVK doesn't and it't horribly slow and eats loads of CPU time on the client  - my observations are a bit empirical but I find it impractical on large changesets.
[18:54] <jelmer> awilkins: svk probably does more than just fetch the revisions though
[18:55] <awilkins> jelmer: That's kinda the point ; I'm not sure what it's doing but it's just fetching one atomic commit (for a lot of files, thanks), either as diffs or whole revisions, and applying it to a local repository
[18:55] <xif> jelmer: can I write, in Python, an extension that adds this feature?
[18:56] <jelmer> xif: probably, although it may be necessary to make some changes to the core of bzr as well
[18:56] <jelmer> xif: it's probably a good idea to bring it up on the mailing list
[18:57] <xif> jelmer: hm, really?  all we're talking about is a script that runs just before the commit and does a regexp replace on committed files.
[18:57] <jelmer> xif: it's harder than that. You also don't want "bzr status" to report those files as modified
[18:57] <xif> I could implement it with svn hooks if I wanted to, without touching the svn codebase or even writing an extension.
[18:58] <jelmer> or "bzr diff" to show the lines with the keywords on them as changes
[18:58] <jelmer> awilkins: it would surprise me if replay had a significant impact on the speed of bzr-svn
[18:59] <xif> all I want is that if I commit a file that contains "$Rev: foo$", foo would be replace by the current revision before the commit.
[19:00] <jelmer> you may be able to do that using a pre-commit, but I'm not sure whether such a hook is allowed to change the working tree
[19:01] <xif> jelmer: thanks.
[19:01] <jelmer> xif: afaik there's no way to do so with svn
[19:02] <awilkins> jelmer: Hmm ; I guess it's an idea that's sticking in my head because it takes 5 minutes of CPU time to sync a single revision consisting of 1MB of XML spread across 708 files in SVK..... it would be quicker to export the files locally and check them in there, for heavens sake. I shall have to try bzr-svn and see how it compares on the same tasks
[19:03] <jelmer> awilkins: is SVK using svn_ra_do_update() and not just svn_ra_get_file() ?
[19:03] <jelmer> (708 roundtrips per revision instead of 1)
[19:04] <awilkins> jelmer: Doesn't explain why it's pegging the CPU for 5 minutes, but i'll look at the source
[19:15]  * awilkins head pounds from having to read perl
[20:32] <Treeform> how is TortoiseBZR shaping out? looking at the page its still below bata quality! Is that true?
[20:43] <bronger> What is the difference between svn2bzr and bzr-svn?
[20:44] <jelmer> Treeform: yeah, it's a proof of concept and there's nobody actively working on it
[20:45] <jelmer> bronger: svn2bzr works on svn dump files and does't require a patch python-subversion
[20:45] <jelmer> bronger: bzr-svn requires a patched python-subversion but is better tested, allows pushing back to Subversion and actively maintained
[20:45] <bronger> Thanks, but what is the difference as far as the resulting branch is concerned?
[20:46] <jelmer> not much
[20:47] <jelmer> the one created with bzr-svn allows you to make changes based on it and push those changes back into svn
[20:47] <bronger> The problem is that I cannot access the SVN repository as an admin, so I have no dump;  I wonder whether this means that I "lose" anything.
[20:47] <jelmer> bronger: bzr-svn allows working with a remote svn repository
[20:47] <jelmer> svn2bzr does not
[20:50] <bronger> Mmmh ... good (for me).  So, svn2bzr is for real migration then, and of no value if you actually want to keep SVN?
[20:50] <Odd_Bloke> bronger: I also believe I'm correct in saying that Debian and so Ubuntu ship the ready-patched bindings, so you wouldn't have to do it yourself on those cases.
[20:50] <bronger> Odd_Bloke: Yes, at least branchin works nicely.
[20:52] <bronger> Speaking about Ubuntu ... adding the package sources for the current version (taken from Bazaar's HP), I lost bzr-svn because it wanted an older version of bzr.  It was not included into the repository, too.
[20:52] <jelmer> bronger: the up to date bzr-svn package is "deb http://samba.org/~jelmer/debian/ unstable/"
[20:53] <jelmer> bronger: svn2bzr is just older
[20:56] <Treeform> jelmer, thanks
[21:02] <schierbeck> jelmer: what do you think about the fancy-tags patch?
[21:02] <schierbeck> ready for inclusion?
[21:05] <jelmer> sorry, haven't had time to look at it yet
[21:06] <schierbeck> np
[21:11] <bronger> jelmer: Thanks, works nicely!
[22:14] <Verterok> moin
[22:16] <poolie> hi
[22:16] <Verterok> poolie: hi
[22:18] <Verterok> jelmer: Hi, do you have a few minutes?. It's a about bzr-svn and OS X 10.4
[22:18] <jelmer> Verterok, sure
[22:18] <Verterok> great!
[22:19] <jelmer> abentley: what are your plans for bundlebuggy? Is it still being actively developed or in maintainance mode until launchpad takes over?
[22:20] <Verterok> jelmer: I spent the last two days trying to compile the svn python-bindings with XCode-2.5 (the latest version for 10.4)
[22:20] <Verterok> (I'll add a Tiger section in the wiki page tonight)
[22:20] <ubotu> New bug: #185180 in bzr "Better messages when upgrade fails" [Undecided,New] https://launchpad.net/bugs/185180
[22:21] <Verterok> the main problem is that Xcode-2.5 kill the libtool shipped with 2.4
[22:22] <Verterok> after installing libtool from macports all worked like a charm :)
[22:23] <asabil> schierbeck: ping ?
[22:23] <Verterok> all this introduction is to tell that I'ld like to build a pkg for svn-1.5 + bindings for OS X
[22:24] <jelmer> Verterok, ah, that would be awesome
[22:24] <jelmer> the number of people that has been trying to use bzr-svn on Mac OS X has surprised me
[22:25] <Verterok> jelmer: a friend need bzr-svn features to keep in sync with a svn repo (hosted by his client)
[22:26] <abentley> jelmer: active development
[22:26] <jelmer> abentley: Cool, thanks!
[22:27] <Verterok> jelmer: he found the build a limitation to his deployment needs (around 7 workstations need to work with bzr-svn)
[22:28] <jelmer> Verterok: if there's anything I can help with, please let me know.
[22:29] <Verterok> jelmer: I don't know where to look for instructions about how subversion is packaged for OS X
[22:32] <schierbeck> asabil: pong
[22:34] <asabil> schierbeck: did you merge the fancy tags crack to the baseline ?
[22:35] <schierbeck> asabil: not yet, i need another core dev to vouch in
[22:35] <Verterok> jelmer: (last question) bzr-svn needs a complete subversion install or with the libs+bindings is enough?
[22:35] <jelmer> Verterok: libs+bindings is sufficient
[22:36] <jelmer> Verterok: there doesn't appear to be packaging data in svn's svn
[22:36] <Verterok> oh, great!
[22:37] <asabil> oh oki
[22:37] <Verterok> jelmer: thanks,  I'll neeed  to get a collabnet user a search inside collbnet documentation
[22:37] <asabil> maybe we can poke someone schierbeck ?
[22:38] <schierbeck> oh, i'm not sure if jelmer has time for it >:)
[22:39] <Verterok> jelmer: (real last question :-))  the libs+bindings can live side by side with a previous svn, like 1.4.4?
[22:43] <jelmer> Verterok: I don't think they can live together with bindings form an earlier version
[22:43] <jelmer> schierbeck: Sorry, hopefully I can have a look tomorrow
[22:44] <jelmer> I have an exam tomorrow that I still need to do some final preparation for
[22:44] <Verterok> jelmer: ok, thanks a lot!. good luck with your exam!
[22:47] <schierbeck> jelmer: me too
[22:47] <schierbeck> sucks...
[22:48] <awilkins> What is it that the Pywin32 package contributes to running bzr on Windows?
[22:58] <poolie> awilkins, from memory, we use it to take file locks, manipulate the terminal
[22:58] <poolie> understand errno values
[22:58] <poolie> stuff like that
[22:59] <awilkins> Hmm, I've been running without it ... I wonder if it's responsible for some of the errors I've been seeing
[23:00] <poolie> igc, hi
[23:00] <igc> hi poolie
[23:01] <spiv> And mark files hidden, I think?
[23:02] <poolie> awilkins, if it's said to be optional but it doesn't work without it, that would be a bug, one way or the other....
[23:02] <poolie> igc, quick call?
[23:02] <igc> poolie: 10 minutes ok?
[23:02] <poolie> sure, call my mobile when you're ready?
[23:02] <igc> sure
[23:03] <poolie> have you seen jam?
[23:03] <poolie> is he away this week?
[23:03] <poolie> s//today
[23:03] <poolie> he has been answering mail i guess
[23:05] <spiv> Yeah, he even reviewed some of my patches.
[23:06] <jelmer> man, fate is cruel. I have an exam on unit testing on the thursday of the Bazaar sprint :-/
[23:08] <CardinalFang> I added a simple patch/bug.  ubotu should have mentioned it by now.  https://bugs.launchpad.net/bzr/+bug/185191
[23:08] <ubotu> Launchpad bug 185191 in bzr "add mnemonic diff to "commit" info {with patch}" [Undecided,New]
[23:08] <CardinalFang> Heh.
[23:08] <awilkins> I swear that thing waits until it sees you in channel before it talks....
[23:09] <fullermd> AFAIK, it triggers off the bug mailing.  And I haven't gotten that bug yet, so...
[23:09] <awilkins> I think it watches for urls
[23:09] <awilkins> https://bugs.launchpad.net/bzr/+bug/185191
[23:09] <ubotu> Launchpad bug 185191 in bzr "add mnemonic diff to "commit" info {with patch}" [Undecided,New]
[23:09] <fullermd> Well, it grabs the URL's.  And bugs named by number.  Like, I could ask about bug 185190...
[23:09] <ubotu> Launchpad bug 185190 in ubuntu "City (Pittsburgh) Associated w/ Wrong Timezone" [Undecided,New] https://launchpad.net/bugs/185190
[23:10] <awilkins> bug replay
[23:10] <awilkins> 185190
[23:10] <fullermd> But it'll also announce the filed bug when the mail hits.
[23:11] <ubotu> New bug: #185191 in bzr "add mnemonic diff to "commit" info {with patch}" [Undecided,New] https://launchpad.net/bugs/185191
[23:11] <fullermd> Like so.
[23:11]  * fullermd pets ubotu.
[23:16] <ubotu> New bug: #129334 in bzr-svn "Unicode exception while branching" [Low,Fix committed] https://launchpad.net/bugs/129334
[23:16] <schierbeck> asabil: try pulling from ~bzr-gtk/bzr-gtk/viz-tags with the --overwrite flag
[23:16] <asabil> k
[23:16] <schierbeck> i've dropped using markup for now, i'll just deal with the tooltips when i have to
[23:18] <asabil> ok
[23:49] <awilkins> !word
[23:49] <ubotu> A comprehensive list of of Windows-equivalent applications in Linux can be found at http://www.linuxrsp.ru/win-lin-soft/table-eng.html and https://wiki.ubuntu.com/WhatWindowsUsersWant
[23:52] <cpinto> hi all
[23:52] <cpinto> i'm using bzr to be able to work disconnected from a subversion repo. after fetching the sources i did a bzr unbind. worked a little bit on them, committed stuff and i just did a bzr bind + bzr update as to update from the central repository. now I have a bunch of pending merges mixed with a few not yet merged changes to the code.
[23:52] <cpinto> is there anyway to commit only the pending merges?
[23:56] <ubotu> New bug: #185200 in bzr ""database is locked" bzr internal error" [Undecided,New] https://launchpad.net/bugs/185200
[23:58] <fullermd> Not really, no.  That's why you commit before update   8-}