[01:09] <igc> morning
[01:51] <abadger1999> lkoggerhead question -- Is it possible to configure it to serve on a subdiretory?
[01:52] <abadger1999> *loggerhead
[01:52] <abadger1999> Like this:
[01:52] <abadger1999> http://localhost/bzr/myproject/branch-foo
[01:53] <abadger1999> I haven't been able to move it away from  this style of url http://localhost/myproject/branch-foo
[01:56] <lifeless> abadger1999: yes, python-paste permits this
[01:56] <lifeless> sorry pastedeploy
[01:57] <abadger1999> lifeless: Do you know the config option I'd need to change?
[01:57] <lifeless> not offhand
[01:57] <lifeless> uhm
[01:57] <lifeless> are you using WSGI, serve-branches or bzr serve --http ?
[01:57]  * abadger1999 is also aiming to get this working with mod_wsgi... but that would come after getting it working at all.
[01:58] <abadger1999> mod_wsgi is my goal but I've experimented with both of the others.
[01:58] <lifeless> abadger1999: I wouldn't sequence things like that; just aim directly at your goal
[01:58] <lifeless> wsgi apps can be layer
[01:58] <abadger1999> lifeless: Alright -- mod_wsgi :-)
[01:58] <lifeless> to do path manipulation etc in containing apps
[02:02] <lifeless> look for PrefixMiddleware in serve-branches
[02:03] <mwhudson> abadger1999: serve-branches --prefix should do that, how are you proxying to it?
[02:04] <abadger1999> mwhudson: I'm not proxying.  My last bit of trying has been based on this: http://blog.projectfondue.com/2009/11/26/loggerhead-and-mod-wsgi
[02:05] <mwhudson> abadger1999: then --prefix bzr should Just Work, i think
[02:06] <abadger1999> lifeless: There's no PrefixMiddleware in serve-branches -- the wsgi script I was using has PrefixMiddleware(app, prefix='')
[02:06] <abadger1999> Changing that to prefix='/bzr' didn't work out very well.
[02:06] <abadger1999> It made the front page correct but links to subpages had no /bzr in the url.
[02:07]  * abadger1999 tries serve-branches --prefix
[02:10] <lifeless> hmm my trunk of loggerhead must be stale
[02:12] <abadger1999> mwhudson: Pretty good.  It's interesting that it's serving on both /bzr and / but the links look consistent
[02:12]  * abadger1999 looks at code
[02:12] <lifeless> igc: $ bzr pull
[02:12] <lifeless> Using saved parent location: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/
[02:12] <abadger1999> I'm using the 1.17 release right now.
[02:12] <lifeless> No revisions to pull.
[02:12] <lifeless> my serve-branches has prefix middleware
[02:12] <abadger1999> So it might be that things have changed since then
[02:12] <lifeless> revno 345
[02:13] <mwhudson> lifeless: that's not lp:loggerhead any more
[02:13] <lifeless> mwhudson: oh
[02:13] <lifeless> mwhudson: what is then ?
[02:13] <lifeless> and why did it change?
[02:13] <mwhudson> lifeless: i think it's called trunk-ric
[02:14] <mwhudson> lifeless: and it was to do with upgrading to 2a
[02:14] <lifeless> ugh
[02:14] <mwhudson> it wasn't me
[02:14] <lifeless> I do so hate that approach
[02:14] <lifeless> no, I know
[02:14] <lifeless> its the approach thumper and igc advocated, IIRC
[02:14] <thumper> ?
[02:15] <igc> lifeless: I agree it's annoying that lp:xxx can change and we don't follow the new location
[02:16] <igc> I'm pretty sure there's a bug for that
[02:17] <thumper> I think bzr should store the url for before and after resolution
[02:17] <thumper> and warn the user if they change
[02:17] <thumper> or something
[02:17] <igc> thumper: it only stores the "after resolution" info right now
[02:18] <thumper> igc: right
[02:19] <lifeless> there is a bug about us storing the directory service url
[02:19] <lifeless> however I'm complaining about the manner of upgrade where a new branch is used
[02:19] <igc> lifeless: I got that
[02:19] <lifeless> which does, I admit, interact with that bug.
[02:20] <lifeless> however, even if we had fixed that bug, people following our docs that don't use launchpad would still have the same pain.
[02:45]  * igc out for a few hours
[03:05] <mwhudson> jelmer: looks like you fixed that problem you talked about earlier?
[03:18] <lifeless> thumper: have you looked at any rich root branches rev 1 in loggerhead before ?
[03:19] <thumper> lifeless: no, but I used diff locally
[03:19] <thumper> lifeless: I'll check now
[03:19] <thumper> it could be a bug in loggerhead
[03:19] <lifeless> I branches the branch you're complaining about
[03:19] <lifeless> it checks clean
[03:19] <lifeless> st -r 0..1 is clean
[03:20] <lifeless> diff -c 1 is clean
[03:20] <thumper> weird
[03:20] <thumper> ok, not a bzr-hg bug then
[03:20] <lifeless> the / is simply the root id being added, its normal, and IMO not a serious bug that loggerhead shows it
[03:20] <thumper> must be a loggerhead display bug
[04:32] <abadger1999> mwhudson: Ah.... I vaguely remember this issue.
[04:33] <abadger1999> mwhudson: For some reason loggerhead doesn't handle URLs without a trailing "/" quite right.
[04:34] <abadger1999> mwhudson: With mod_wsgi and clicking on a directory of branches (as opposed to directly onto a branch), it goes to http://localhost/bzr/python-fedora <= no trialing slash
[04:34] <abadger1999> mwhudson: That redirects to http://localhost/python-fedora/
[04:34] <mwhudson> abadger1999: that's quite strange
[04:35] <abadger1999> mwhudson: So something is dropping the '/bzr/' in there
[04:35] <mwhudson> abadger1999: do you have a prefixmiddleware in your wsgi stack?
[04:35] <abadger1999> mwhudson: Using serve-branches --prefix yields a slightly different issue.
[04:35] <abadger1999> mwhudson: Yeah Letme upload the script
[04:36] <mwhudson> abadger1999: what i know about mod_wsgi setup could fit quite comfortably on the back of a postage stamp, btw
[04:36] <abadger1999> http://toshio.fedorapeople.org/loggerhead.wsgi
[04:37] <abadger1999> This line probably isn't needed: os.environ['loggerhead.static.url'] = '/bzr'
[04:38] <abadger1999> mwhudson: So serve-branches.... I invoke it like this:  serve-branches --prefix bzr /var/www/bzr
[04:38] <abadger1999> mwhudson: Then if I browse to http://localhost/bzr  <= No trailing slash
[04:38] <abadger1999> mwhudson: There's no /bzr/ in the urls
[04:41] <mwhudson> abadger1999: i know that pastedeploy expects that the /bzr part of the path is in the script_url in the environment that it sees
[04:41] <mwhudson> abadger1999: is that something you can control from the mod_wsgi side?
[04:41] <mwhudson> maybe i mean path_info there
[04:42] <abadger1999> mwhudson: Hmm... Let me see if I can
[04:42]  * abadger1999 knows how to do that for TurboGears apps
[04:44] <mwhudson> jelmer: ayt?
[05:03] <abadger1999> mwhudson: Huh.... I'm a little bit stumped... I've got script_name as /bzr and path_info as /stats/changes or etc... seems to work.
[05:03] <mwhudson> abadger1999: hmm
[05:03] <abadger1999> mwhudson: But when I go to /bzr/python-fedora my instrumented wsgi script doesn't seem to get invoked at all.
[05:03] <mwhudson> well working > understanding i guess :)
[05:03] <mwhudson> ah
[05:04] <abadger1999> And that gets redirected to /python-fedora where it fails.
[05:04] <mwhudson> that sounds like an apache/mod_wsgi problem then?
[05:04] <abadger1999> So ....  it seems like something is doing the redirect before the wsgi app.
[05:04] <abadger1999> I'm going to pursue that until I find out different :-)
[05:24] <abadger1999> mwhudson: Okay... this gets stranger although it's still not looking like loggerhead's fault => firefox doesn't work but wget redirects correctly.
[05:25] <mwhudson> abadger1999: sounds like you either need to go to bed or get drunk :-)
[05:25] <abadger1999> mwhudson: yeah, I'm going to second that.
[05:25] <abadger1999> Thanks for the help!
[05:25] <mwhudson> abadger1999: np
[05:29] <fullermd> Why is this an "or"?  Does nobody have the foresight to have a wet bar built in to the nightstand?
[05:31] <AndrewLuecke> G'day, does bazaar have a way to restrict&control SSH access?
[05:32] <AndrewLuecke> aah.. nevermind..
[05:32] <AndrewLuecke> Got it ..
[06:42] <igc> back
[06:50] <mwhudson> igc: hi
[06:50] <igc> hi mwhudson
[06:51] <mwhudson> igc: i just wanted to encourage you to just make/land changes to loggerhead trunk if you feel they are improvements
[06:52] <igc> mwhudson: ok. I'm hoping to start looking at the loggerhead stuff any day now - building a Windows 2.2 installer currently
[06:53] <mwhudson> igc: ah ok
[06:53] <mwhudson> igc: loggerhead should be more fun than that :)
[06:53] <igc> mwhudson: I've been reading up on WebOj and Chameleon while up at the hospital in recent days as well
[06:53] <igc> mwhudson: yes :-)
[06:54] <mwhudson> i've been feeling bad for being a slack maintainer lately, and it looks like i'll be getting even less time for it
[06:54] <mwhudson> igc: i think chameleon is probably a pure win if we can keep streaming
[06:54] <mwhudson> simpletal is kinda horrible
[06:54] <igc> mwhudson: np. I'll be sure to ping you asking for advice if I have any concerns about changes
[06:55] <mwhudson> igc: cool
[06:55] <igc> mwhudson: yeah, I find TAL+TALES+METAL a lot less readable than jinja2 but I'll survive :-)
[06:56] <igc> mwhudson: I'm curious about the stability issues as well
[06:56] <mwhudson> well if you want to rewrite all the templates...
[06:56] <mwhudson> igc: so are we all, i think
[06:56] <igc> mwhudson: is there a 60 second summary of what not to touch, e.g. the threading code?
[06:58] <mwhudson> igc: i'd consider most of it fair game i guess :)
[06:59] <mwhudson> igc: the code for the url dispatch, information gathering and rendering stages is fairly separate
[06:59] <mwhudson> igc: the problems tend to be in the middle stage, unsurprisingly, so it's probably best to at least be careful there
[07:00] <igc> mwhudson: by middle, you mean "info gathering"?
[07:00] <igc> the "interfacig to bzrlib" bit?
[07:00] <mwhudson> igc: yes
[07:02] <igc> mwhudson: ok
[07:17] <mkanat> I'm seeing a lot of what seem to be spurious merge conflicts when I try to update a bzr branch from Bugzilla 3.4 to Bugzilla 3.6.
[07:17] <mkanat> Perhaps there's some documentation that I haven't read?
[07:39] <AndrewLuecke> Sorry to bug you guys again.. But we are branching a SVN tree into bzr, and would like to still be able to pull off their tree, as well as maintain history.. I assume  bzr-svn is the best way of doing this?
[07:39] <mwhudson> AndrewLuecke: yes
[07:39] <AndrewLuecke> ok.. cool..
[07:54] <AndrewLuecke> This is SOOOO much nicer than mercurial's and gits way of doing it
[07:55] <AndrewLuecke> I've spent the last 4 days on this.. And this is soooo streamlined
[07:55]  * AndrewLuecke has become a fanboy suddenly
[08:26] <igc> hi bialix
[08:26] <bialix> hi igc!
[08:26] <bialix> glad to see you
[08:26] <igc> bialix: ditto
[08:27] <bialix> I've used explorer yesterday on colo workspace. nice work with context menu
[08:27] <igc> bialix: if you get some time soon, can you try the latest bzr-windows-installers scripts?
[08:28] <bialix> I think we need even better support for colo
[08:28] <igc> +1 from me on that
[08:28] <bialix> igc: perhaps on weekends only
[08:28] <bialix> is it ok for you?
[08:28]  * bialix trying to finish main work to be able attend UDS
[08:29] <igc> bialix: whenever suits you is good. I'm trying to get a bzr 2.2 build with Python 2.6 (and I'm struggling)
[08:29] <bialix> igc: I need to make auto-generated en.po translation to be LF-only as well. is it still a problem?
[08:30] <igc> bialix: no, I think the problem is elswwhere
[08:30] <igc> elsewhere
[08:30] <bialix> python 2.6... I've tried to avoid it in my work, just because there is some struggles with py2exe
[08:30] <igc> my current struggle is probably something to do with how py2exe is configured
[08:31] <bialix> igc: will be nice if you send me a mail closer to weekend and highlight the moments I should check/help
[08:31] <igc> there's a PyQt4.uic.port_v3 on the filesystem but py2exe is falling over becuae it con't find it
[08:31] <bialix> there is not much configuration knobs in the py2exe
[08:31] <bialix> maybe env path
[08:32] <igc> bialix: hmm - maybe I need to look there
[08:33] <igc> bialix: i'ts very frustrating when it fails because it gives you so little to work out what's wrong :-(
[08:33] <bialix> igc: there is something like debug output in py2exe, at least it can generate full dependency graph for you
[08:36] <bialix> igc: which version of PyQt I should use?
[08:36] <igc> I'm trying to build with Python 2.6.5 and PyQt 4.7.2
[08:36] <igc> bialix: ^^^
[08:36] <bialix> ok, I'll grab those
[08:37] <igc> bialix: thanks
[08:38] <igc> bialix: with rev 108 of bzr-windows-installers, the command to run is ...
[08:38] <igc> build.py installers --standalone-only
[08:39]  * bialix nods
[08:39]  * bialix has pyqt 4.7.0 as well
[09:19] <lifeless> thumper: https://edge.launchpad.net/codewiki
[09:35]  * igc dinner
[09:52] <vila> lifeless: heads-up, feed-pqm doesn't prefix your commit messages with (lifeless)
[09:52] <lifeless> vila: interesting; file a bug on hydrazine please
[09:53] <vila> lifeless: I don't think so, we tend to use a rather liberal prefix there (mbp, for parthm) for example
[09:53] <lifeless> vila: if we were to fix this, where would it get fixed?
[09:54] <vila> lifeless: we never fixed pqm-submit, why should we fix feed-pqm ? :->
[09:54] <lifeless> because a smooth toolchain is nice to work with
[09:54] <lifeless> so I repeat
[09:54] <lifeless> vila: if we were to fix this, where would it get fixed?
[09:55] <vila> lifeless: educate the user :)
[09:55] <lifeless> vila: I don't understand why you don't want this automated.
[09:55] <vila> lifeless: if that doesn't work, joking, let me finish :)
[09:56] <vila> it that doesn't work, then either pqm or feed-pqm, probably the later, but the rules need to be defined, like, generate a prefix only if none are present and put... username there?
[09:57] <lifeless> vila: this, file a bug
[09:57] <lifeless> *thus*
[09:57] <lifeless> and yes, hydrazine for now, I think
[14:19] <ezod> suppose a remote (upstream) bound branch is at revision N, and i make a local commit, so i'm at revision N + 1, then i run bzr update, putting me back to N
[14:19] <ezod> is there any way to get revision N + 1 changes back?
[14:22] <awilkins> ezod, update again (presuming you did an update to -r -2 to get to N)
[14:23] <ezod> no, rev N + 1 was local only
[14:23] <ezod> will this work:
[14:23] <ezod> bzr pull . --overwrite -r revid:<N+1>
[14:23] <ezod> perhaps?
[14:23] <awilkins> ezod, try `bzr heads` to find the revision number
[14:25] <ezod> `bzr heads` doesn't return anything
[14:25] <ezod> oh
[14:25] <ezod> bzr heads --dead does
[14:26] <awilkins> ezod, find your revision and pull that
[14:26] <ezod> revid is email-timestamp-string
[14:27] <ezod> ok cool, will try
[14:27] <awilkins> bzr pull -r revid:<blah>
[14:28] <ezod> awilkins: thanks, seems to have worked :)
[15:01] <c_korn> hello, how can I fix this error ? http://pastebin.com/XVcmjnWg
[15:03] <awilkins> c_korn, You need to upgrade the remote repository
[15:03] <awilkins> I believe there's a button in LP for that
[15:05] <awilkins> Or take a local branch that isn't rich-root
[15:11] <jam> morning all
[15:11] <jam> hey vila, I got most of the merge_sorted stuff working
[15:11] <jam> some edge cases that i want to write tests for first
[15:11] <vila> jam: morning jam !
[15:12] <vila> jam: good work !
[15:12] <vila> jam: so youwant to write test first ? :-P
[15:12] <jam> I do that sometimes :)
[15:12] <jam> seriously, when it is tricky edge case stuff, I usually do
[15:12] <jam> to make sure that I'm actually exposing the code I think I ame
[15:12] <jam> am
[15:13] <vila> yeah, that's the idea ;-)
[15:13] <vila> by the way, have a look at bug #489179
[15:14] <vila> jam: not for the bug itself, bug look at revno 4081.2.2 with qlog
[15:15] <vila> jam: Iwas surprised by the revno numbering here, as if daggy fix could somehow violate the stability,
[15:15] <vila> jam: I didn't dig but thought you may be interested
[15:16] <jam> daggy shouldn't affect numbering
[15:18] <c_korn> awilkins: ok, I think I found the button.
[15:19] <c_korn> this is it I think: http://www.ubuntu-pics.de/bild/50919/screenshot_001_4B7Mnw.png
[15:20] <vila> jam: I realize that, but just have a look
[15:20] <awilkins> c_korn, You might want to warn the rest of the dev team :-)
[15:20] <c_korn> awilkins: yes, I am currently doing this
[15:36] <jam> vila: so what am I looking at wrt 4081.2.2 ?
[15:36] <jam> vs log file -v ?
[15:37] <jam> I see a lot of files merged in 4081.2.2, but that is expected, since it is all of 5112-4081 from bzr.dev being merged in one go
[15:37] <vila> jam: just a sec, killed the wrong qlog seconds ago
[15:38] <jam> if you are wondering about the revno, it is because they merged bzr.dev into the changelog branch, not based the changelog branch on bzr.dev
[15:41] <vila> jam: ha, right, twice, I've been tricked by qlog for the other case but it's right here :-)
[15:45] <vila> jam: I think my initial surprise was more about the -n0 -v revno being so far away from the revs shown by -n0, but that may just be the revno scheme after all
[15:49] <jam> I don't quite understand "the -n0 -v revno"
[15:49] <jam> when I do "bzr log -v -r 4081.2.2" w/ bzr.dev, I only get the one rev
[15:53] <Lo-lan-do> Hi all
[15:53] <jam> morning Lo-lan-do
[15:56] <Lo-lan-do> jelmer: I think I found a race condition in bzr-svn the hard way :-(
[15:59] <jelmer> Lo-lan-do: hmm?
[16:00] <Lo-lan-do> Someone did an svn commit just as I was starting pulling a branch onto my bzr checkout
[16:01] <Lo-lan-do> SVN did record both his revision and my series (of 21) revisions, but now I get an assertion error in my bzr checkout
[16:02] <Lo-lan-do>  File "/usr/lib/python2.5/site-packages/bzrlib/plugins/svn/branch.py", line 484, in get_rev_id/assert revmeta.get_revno(mapping) == revno
[16:14] <Lo-lan-do> Okay, I removed revprops, uncommitted and pulled again, and now I'm fine again.
[16:16] <jelmer> Lo-lan-do: his changes interrupted your push of a serie of revisions?
[16:17] <Lo-lan-do> Unfortunately not.
[16:17] <Lo-lan-do> I think his commit happened between the time bzr had read the existing revprops and the time bzr started pushing.
[16:18] <jelmer> Lo-lan-do: but it's now interwoven with your changes?
[16:18] <Lo-lan-do> SVN's revision history was, say, 100-101-102-103, with 101 being my coworker's commit and 102-103 being mine
[16:19] <Lo-lan-do> But bzr log only displayed 100-102-103
[16:19] <Lo-lan-do> 102 had 100 as its parent bzr-wise
[16:19] <jelmer> bug 515850
[16:20] <Lo-lan-do> Sounds like exactly that, indeed :-)
[16:20] <Lo-lan-do> Sorry for the interruption.
[16:23] <tyarusso> I know this is an odd request, but does anyone have a side-by-side technical comparison of bzr against RCS?
[16:31] <jelmer> Lo-lan-do: np, it is an important bug to fix
[16:32]  * jelmer waves to jam, vila
[16:32] <jelmer> tyarusso: hi
[16:32] <jelmer> tyarusso: I'm not aware of one - the major difference seems to be that RCS is per-file, Bazaar versions an entire tree
[16:32] <tyarusso> hey jelmer
[16:33] <jelmer> tyarusso: I'm not sure if that helps at all.
[16:33] <jam> morning jelmer
[16:33] <tyarusso> dunno
[16:33] <tyarusso> The main thing that annoys me with RCS is that the revision files aren't "hidden", so directories get really cluttered.
[16:34] <jelmer> jam: looks like I'll need packs for bzr-git's cache anyway
[16:34] <jelmer> jam: group compress doesn't rely on parent information right?
[16:34] <jelmer> jam: (for performing well, I mean)
[16:35] <jam> jelmer: correct
[16:35] <jam> though you need some sort of 'grouping' key
[16:35] <jam> atm we use file-ids and sort them
[16:35] <jam> which often works pretty well
[16:35] <jelmer> that's fine, I'd want Git paths in that case
[16:35] <tyarusso> What happens if you do a bzr init in a directory that already has a repo going?  (For instance, if you have a bunch of scripts that want to version something in /etc, and they don't know which script will run first. (not using etckeeper))
[16:35] <jam> well, you'd want filenames not paths, I would guess
[16:35] <jam> or reverse paths or something
[16:35] <jam> all files in a dir don't often compress as well as all files named Foo
[16:36] <jelmer> jam: Sorry, that's what I meant
[16:36] <jelmer> it's the same key that git uses to compress its packs
[16:36] <jelmer> jam: Basically, I'd like to cache git Tree objects and Blob objects for symlinks
[17:05] <RobOakes> Morning everyone.  I am trying to push a bzr branch into an empty svn repository (for backup/collaboration purposes).  However, when I run bzr push https://path/to/repo, it tells me that the branches have diverged.
[17:05] <RobOakes> Does anyone know how I can push my local branch to the remote server with bzr-svn?
[17:06] <tyarusso> This there a way to give each versioned file a description?  For instance "Config file for MySuperCoolProgram".
[17:07] <jelmer> RobOakes: your bzr branch has a different history than an empty svn branch (which has exactly one commit on it)
[17:07] <jelmer> RobOakes: If you push to a location that doesn't exist yet things should work
[17:08] <RobOakes> For example: http://server/repo/subdir?
[17:09] <jelmer> yeah
[17:09] <jelmer> provided subdir doesn't exist yet
[17:09] <RobOakes> Oh, that worked great.  Thanks!
[17:16] <Torne> is it intentional that pressing 'f' in the builtin shelve command selects "yes" for all remaining hunks?
[17:16] <Torne> it seems much more logical for it to select "no", since that's the default
[17:26] <msmith> hello everyone, i have a question about bzr-svn on debian
[17:28] <msmith> when installing on debian using apt-get i get the following:
[17:29] <msmith>  bzr-svn: Depends: bzr (< 1.6~) but 2.0.3-1~bpo50+1 is to be installed
[17:29] <tyarusso> I suppose I *could* create a local branch for each file and name those, but that seems a little silly.
[17:30] <msmith> is there a repository i can add to my sources.list that would contain an updated version?
[17:31] <Peng> msmith: Yes, unless the repository is out-of-date too.
[17:31] <Peng> Don't have a link right this second, though.
[17:32] <Peng> msmith: Try https://launchpad.net/~bzr/+archive/ppa, or possibly https://launchpad.net/~bzr-svn/+archive/ppa or something
[17:32] <Peng> IIRC there is a bzr-svn ppa, but I don't remember the link. :-\
[17:35] <Torne> msmith: which version of debian are you using? all versoins should have a matching bzr-svn for the bzr they have
[17:35] <Torne> msmith: it looks like you maybe installed bzr from somewhere else
[17:35] <Peng> Err, right, Debian. The PPA's out, then...
[17:35] <Peng> Sorry.
[17:36] <msmith> :)
[17:36] <Torne> msmith: ah, you have bzr from lenny-backports
[17:36] <Torne> msmith: there's no bzr-svn backported to lenny.
[17:36] <Torne> either install the testing/unstable version of bzr along with all its dependencies, and the matching version of bzr-svn from testing/unstable, or downgrade to the lenny version of bzr, or build your own package..
[17:36] <Torne> (or ask someone else for a backport :)
[17:38] <msmith> ok, thanks.  i'll try to follow that path and scream for help if i fall off a cliff
[18:25] <krisives-gearbox> I have 2 branches that didn't start as the same code, but I'm trying to get them to be equal. I've made both a bzr repo and added all the files. What strategy should I use to try and get them to be equal?
[19:34] <rellis> Is there a way to get a commit history for a particular user with bzr?
[19:42] <krisives-gearbox> http://superuser.com/questions/128540/bazaar-merge-identical-files
[19:51] <vila> krisives-gearbox: you should put one branch under bzr and then, override all the files with your second branch and finally do 'bzr diff'
[19:51] <krisives-gearbox> override>
[19:51] <krisives-gearbox> ?
[19:51] <vila> copy over
[19:52] <krisives-gearbox> if I do that in a new area I can then push/pull those diffs into one of the original to make them all equal
[19:53] <vila> when a file is first added to a branch, it receives and unique ID, if you so that in two different (unrelated) branches, the "same" file get a different ID, when your try to merge bzr then see them as different and move one away (.moved)
[19:53] <vila> s/and unique/ a unique/
[19:53] <vila> meh s/so that/do that/
[19:56] <vila> krisives-gearbox: you can't start with two different histories, that's the so-called "parallel import" problem which is yet to be addressed by bzr
[19:58] <krisives-gearbox> One issue with that strategy though
[19:58] <krisives-gearbox> I want to end up with 2 bzr repos
[20:00] <krisives-gearbox> nvm I think I figured it out, I'll let you know how it works
[20:00] <vila> krisives-gearbox: are you sure you don't mean two branches here ? A repo for bzr is just a place to put revisions used by one or many branches
[20:00] <krisives-gearbox> bzr init creates a repo, right?
[20:01] <krisives-gearbox> I probably have that wrong
[20:02] <vila> 'bzr init' creates a branch, a branch uses a repo, if no repo is available to be shared, 'bzr init' will create one for the branch itself, but if you intend to use several branches, you use 'bzr init-repo project' and then 'bzr init project/trunk' and 'bzr init project/feature' etc
[20:03] <vila> trunk and feature will then share the repo created for project
[20:03] <krisives-gearbox> whats the diff between merging repos and branches? or does that question not make sense?
[20:04] <vila> krisives-gearbox: http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief is pretty quick to read
[20:04] <krisives-gearbox> thanks
[20:04] <vila> krisives-gearbox: you merge branches, repos come into play in the background, you rarely use them directly
[20:05] <krisives-gearbox> ok
[20:05] <vila> krisives-gearbox: 'bzr reconfigure' can also be used if you change your mind about your branches layout
[20:05] <krisives-gearbox> I'm still thinking it out hehe
[20:06] <krisives-gearbox> I'm integrating bzr so we can keep client sites up to date
[20:06] <krisives-gearbox> The old system is a hacked PHP upload script garbage blah
[20:07] <vila> "Whatever works" he said :)
[20:08] <krisives-gearbox> Randomly, is there a way to tell `cp` not to copy a specific directory in a recursive?
[20:10] <vila> krisives-gearbox: randomly: cp everything somewhere, delete the offending dir, cp the result ?
[20:10] <krisives-gearbox> good idea
[20:11] <vila> krisives-gearbox: 'tar' has more options, but it's also a bit harder to use it to just copy files around
[20:11] <Peng> You could use rsync. But, again, way complicated.
[20:11] <krisives-gearbox> I think I'm going to do from/* to avoid getting the .bzr
[20:11] <krisives-gearbox> cp -r from/* to/*
[20:11] <Peng> krisives-gearbox: Use "bzr export" to get a copy of a working tree somewhere.
[20:12] <krisives-gearbox> usually would, but doing an "override"
[20:12] <Peng> krisives-gearbox: A repository is just a big bag of revisions. They can be from related branches or not. There's really not much to think about there.
[21:27] <jelmer> jam: what's this history db thing you're working on?
[21:28] <jam> jelmer: caching the dotted revno / merge sorted graph
[21:29] <jam> I've posted some of the results to the list
[21:29] <jam> The basic idea: a dotted revno cache can be shared between branches
[21:29] <jam> as long as you store it based on the mainline revision
[21:29] <jelmer> ah, nice
[21:30] <jam> you can store it completely clustered (only new info per new mainline rev) as long as it is fast to expand
[21:30] <jam> in the process
[21:30] <jam> I also think I can *compute* the merge_sort graph fairly efficiently for new revisions
[21:30] <jam> I think I've found solutions for everything
[21:30] <jam> such that nothing is O(history)
[21:31] <jam> most things are (at worst) O(history since you branched from)
[21:31] <jam> some interesting other results, though
[21:31] <jam> like loading the whole ancestry of mysql in 80ms or so
[21:31] <Peng> Wait, where would this be implemented? bzrlib? A plugin? Something Loggerhead can steal....? :>
[21:31] <jelmer> jam: ooh, that sounds pretty nice :-)
[21:32] <jam> Peng: it is currently a bzr plugin, and inspired from some of the needs of loggerhead and some other bits
[21:32] <Peng> <3
[21:32] <jam> also from codehosting
[21:32] <Peng> Granted, it would take more than this to fix Loggerhead's issues, but... :P
[21:32] <jam> where I'm told there is a table that stores "what revisions are in the ancestry of this revision" for all revisions
[21:33] <jam> Peng: well the root idea was that loggerhead loads the whole history graph when it often doesn't care
[21:33] <jam> so how do we store it
[21:33] <jam> in such a way that we can read only parts of it
[21:33] <jam> and how can we make that efficient against N branches
[21:33] <jam> etc
[21:33] <Peng> Ah. So this could be plugged into a lot of Loggerhead?
[21:33] <jam> Peng: it would replace the RevisionCache, IIRC
[21:34] <jam> you get to keep dotted_revnos in the api
[21:34] <jam> without having them be 2s to compute per branch
[21:34] <jam> get_dotted_revno() for an old revision in mysql takes 13ms
[21:34] <jam> for a new revision, it si about 5-10ms
[21:35] <jam> And I *think* that will scale 'out', where you ask for multiple dotted revnos in a single pass
[21:35] <jam> so it shouldn't be 26ms for 2 dotted revnos, but more 14ms or s.
[21:35] <jam> so
[21:40] <jelmer> jam: what's the status on your pack collection work, is it ready to use in its current form?
[21:41] <jam> not yet
[21:41] <jam> I got distracted by this
[21:43] <Peng> We need to get you to collaborate with yourself from an alternate universe to get both done at once. :)
[21:47] <jelmer> jam: ok
[22:08] <pyMynx> anyone there? ^^
[22:09] <Peng> Possibly!
[22:18] <krisives-gearbox> Thanks again for the help vila
[22:22] <lifeless> jam: before you wrap for the day, could I beg a review?
[22:22] <mwhudson_> jelmer: slightly obscure bzr-git kernel import failure leads to finding a sha1 problem: http://staging.launchpadlibrarian.net/42124151/mwhudson-linux-trunk.log
[22:22] <jam> lifeless: of?
[22:23] <lifeless> https://code.edge.launchpad.net/~lifeless/bzr/commit/+merge/22920
[22:24] <lifeless> jam: ^
[22:27] <jelmer> mwhudson_: That's rev 58, caused by an issue with unusual modes. I'm working on it at the moment.
[22:27] <mwhudson_> jelmer: ahead of me as usual :)
[22:28] <pyMynx> I'm pushing a folder to a server
[22:28] <pyMynx> but the folder on the server is empty after push
[22:29] <pyMynx> all I have is a .bzr folder
[22:29] <pyMynx> :(
[22:29] <jelmer> pyMynx: yes, bzr push does not create a working tree
[22:29] <jam> lifeless: 1) I'm pretty sure the "msg_transport.get_bytes()" is unnecessary as the rest of the code certainly expects 'msgfilename' to be a local object that you can open()
[22:29] <lifeless> jam: yes, but that needs try:finally:close9)
[22:30] <jelmer> pyMynx: you can use the push-and-update plugin to keep the working tree up to date
[22:30] <pyMynx> jelmer: how should I create the branch on the server? I thought I had to push through sftp like in the tutorial
[22:30] <pyMynx> jelmer: oh ok
[22:30] <lifeless> 5 lines, twice, or local function, vs 1 line twice + a 2 line setup
[22:30] <jelmer> pyMynx: bzr push creats a branch (including all history) but not a working tree
[22:30] <lifeless> if we had with, open would be fine.
[22:31] <jam> lifeless: also, you return "" if get_boolean() returns false. Shouldn't you be returning None ?
[22:31] <jam> like the other code path does
[22:31] <lifeless> actually
[22:31] <lifeless> its mixed
[22:31] <lifeless> some code paths return None
[22:31] <lifeless> some return ""
[22:32] <lifeless> if you return None, it raises 'please specify a message via --file or --message'
[22:32] <lifeless> if you return "" you get 'empty commit message supplied'
[22:32] <lifeless> which is a more appropriate error
[22:33] <lifeless> I'll add a comment
[22:33] <jam> lifeless: bb:tweak
[22:33] <jam> lifeless: you also don't have a test case that shows that giving "n" actually cancels the commit
[22:34] <lifeless> sure, I can add one.
[22:36] <pyMynx> jelmer is that the only way? with the plugin? ...i'm following the instruction but it says lp:bzr-push-and-update does not exist yikes!
[22:37] <Peng> pyMynx: lp:~bzr/bzr-push-and-update/trunk WFM
[22:42] <pyMynx> other way to create workingtree on server? :(
[22:43] <Peng> SSH? :D
[22:43] <mwhudson> bzr upload is another option, but it's rather different
[22:43] <Peng> pyMynx: Why are you asking for anotehr solution? What's wrong with bzr-push-and-update?
[22:44] <mwhudson> jelmer: oh, that reminds me, what are the names of the bzr-git caches now?
[22:44] <pyMynx> Peng: I can't install the plugin damn... maybe it's just me
[22:44] <jelmer> mwhudson: everything is in git/ basically
[22:44] <jelmer> mwhudson: .bzr/repository/git/ that is
[22:44] <mwhudson> jelmer: ok
[22:45] <Peng> pyMynx: What error message do you get?
[22:45] <Peng> Hold on.
[22:45] <jelmer> mwhudson: I can give you more specific names if that helps, but supporting git/ would avoid having to play catch up in the future
[22:45] <Peng> pyMynx: Do you have the built-in launchpad plugin disabled for some reason?
[22:45] <mwhudson> jelmer: supporting git/ is probably easy enough
[22:45] <pyMynx> Peng: I've placed the folder inside the plugins folder, but for some reason it doesn't come up when I type bzr plugins
[22:46] <Peng> pyMynx: Did you name it "push_and_update"?
[22:47] <pyMynx> Peng: no, I'll try it now
[22:47] <Peng> pyMynx: Bazaar plugins, like all Python modules, can't have - in their names.
[22:47] <pyMynx> Peng: worked :|
[22:48] <Peng> yay
[22:49] <pyMynx> Peng: :D thank you very much!
[22:49] <pyMynx> Peng: btw sorry if I ask, but does the plugin automatically work when I do push or do I need to type something else? because the docs I found seem very short
[22:49] <Peng> pyMynx: It works automagically.
[22:50] <Peng> pyMynx: But only if a working tree already exists.
[22:50] <pyMynx> Peng: lol
[22:50] <pyMynx> Peng: in local?
[22:50] <Peng> pyMynx: No, in the location you're pushing to.
[22:51] <pyMynx> Peng: all I did was follow the tutorial doing, bzr init, add and then after commit something
[22:51] <Peng> ...
[22:51] <Peng> What are you trying to accomplish?
[22:51] <Peng> Why do you need working trees on servers?
[22:51] <pyMynx> I have a workingcopy of this site on my desktop
[22:52] <pyMynx> I would like to have the same repository on the server
[22:52] <pyMynx> so whenever I change a few things that I like, I push the changes onto the server
[22:53] <Peng> Does the server need a working tree, or just the Bazaar data?
[22:53] <pyMynx> Peng: the server needs all the files in my folder
[22:54] <pyMynx> Peng: I'm sorry for being a pain :)
[22:55] <Peng> pyMynx: Well... if bzr is installed on the server, and a working tree exists, it'll all work automagically.
[22:55] <Peng> pyMynx: If a working tree doesn't exist yet, you need to SSH into the server and run "bzr co" in the branch's directory.
[23:01] <pyMynx> Peng: bzr co should make a tree automatically?
[23:01] <Peng> ...
[23:01] <Peng> cd to a branch without a tree, run "bzr co", and it'll make a tree.
[23:02] <pyMynx> ok thanks
[23:02] <pyMynx> on it!
[23:09] <pyMynx> Peng: nightmare :| no module XMLSerializer
[23:37] <mwhudson> jelmer: +0000 vs -0000 ? argh!
[23:38] <jelmer> mwhudson: yeah, nasty one :-)
[23:38] <jelmer> mwhudson: I need to figure out if git consistently uses -0000 or if it writes +0000 sometimes as well
[23:40] <jelmer> yeah, it seems inconsistent
[23:40] <jelmer> committing manually I can only get it to write +0000
[23:46] <mwhudson> boo :/
[23:46] <mwhudson> another revprop then?