| igc | morning | 01:09 |
|---|---|---|
| abadger1999 | lkoggerhead question -- Is it possible to configure it to serve on a subdiretory? | 01:51 |
| abadger1999 | *loggerhead | 01:52 |
| abadger1999 | Like this: | 01:52 |
| abadger1999 | http://localhost/bzr/myproject/branch-foo | 01:52 |
| abadger1999 | I haven't been able to move it away from this style of url http://localhost/myproject/branch-foo | 01:53 |
| lifeless | abadger1999: yes, python-paste permits this | 01:56 |
| lifeless | sorry pastedeploy | 01:56 |
| 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:57 | |
| 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 | 01:58 |
| lifeless | look for PrefixMiddleware in serve-branches | 02:02 |
| mwhudson | abadger1999: serve-branches --prefix should do that, how are you proxying to it? | 02:03 |
| 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:04 |
| mwhudson | abadger1999: then --prefix bzr should Just Work, i think | 02:05 |
| 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:06 |
| * abadger1999 tries serve-branches --prefix | 02:07 | |
| lifeless | hmm my trunk of loggerhead must be stale | 02:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| igc | lifeless: I agree it's annoying that lp:xxx can change and we don't follow the new location | 02:15 |
| igc | I'm pretty sure there's a bug for that | 02:16 |
| 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:17 |
| thumper | igc: right | 02:18 |
| 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:19 |
| 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:20 |
| * igc out for a few hours | 02:45 | |
| === parthm_ is now known as parthm | ||
| mwhudson | jelmer: looks like you fixed that problem you talked about earlier? | 03:05 |
| lifeless | thumper: have you looked at any rich root branches rev 1 in loggerhead before ? | 03:18 |
| === parthm_ is now known as parthm | ||
| 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:19 |
| 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 | 03:20 |
| === parthm_ is now known as parthm | ||
| abadger1999 | mwhudson: Ah.... I vaguely remember this issue. | 04:32 |
| abadger1999 | mwhudson: For some reason loggerhead doesn't handle URLs without a trailing "/" quite right. | 04:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| abadger1999 | This line probably isn't needed: os.environ['loggerhead.static.url'] = '/bzr' | 04:37 |
| 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:38 |
| 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:41 |
| abadger1999 | mwhudson: Hmm... Let me see if I can | 04:42 |
| * abadger1999 knows how to do that for TurboGears apps | 04:42 | |
| mwhudson | jelmer: ayt? | 04:44 |
| 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:03 |
| 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:04 |
| 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:24 |
| 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:25 |
| fullermd | Why is this an "or"? Does nobody have the foresight to have a wet bar built in to the nightstand? | 05:29 |
| AndrewLuecke | G'day, does bazaar have a way to restrict&control SSH access? | 05:31 |
| AndrewLuecke | aah.. nevermind.. | 05:32 |
| AndrewLuecke | Got it .. | 05:32 |
| igc | back | 06:42 |
| mwhudson | igc: hi | 06:50 |
| igc | hi mwhudson | 06:50 |
| mwhudson | igc: i just wanted to encourage you to just make/land changes to loggerhead trunk if you feel they are improvements | 06:51 |
| igc | mwhudson: ok. I'm hoping to start looking at the loggerhead stuff any day now - building a Windows 2.2 installer currently | 06:52 |
| 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:53 |
| 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:54 |
| mwhudson | igc: cool | 06:55 |
| igc | mwhudson: yeah, I find TAL+TALES+METAL a lot less readable than jinja2 but I'll survive :-) | 06:55 |
| 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:56 |
| mwhudson | igc: i'd consider most of it fair game i guess :) | 06:58 |
| 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 | 06:59 |
| igc | mwhudson: by middle, you mean "info gathering"? | 07:00 |
| igc | the "interfacig to bzrlib" bit? | 07:00 |
| mwhudson | igc: yes | 07:00 |
| igc | mwhudson: ok | 07:02 |
| 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:17 |
| 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:39 |
| AndrewLuecke | This is SOOOO much nicer than mercurial's and gits way of doing it | 07:54 |
| AndrewLuecke | I've spent the last 4 days on this.. And this is soooo streamlined | 07:55 |
| * AndrewLuecke has become a fanboy suddenly | 07:55 | |
| igc | hi bialix | 08:26 |
| bialix | hi igc! | 08:26 |
| bialix | glad to see you | 08:26 |
| igc | bialix: ditto | 08:26 |
| 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:27 |
| 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:28 | |
| 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:29 |
| 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:30 |
| 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:31 |
| igc | bialix: hmm - maybe I need to look there | 08:32 |
| 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:33 |
| 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:36 |
| igc | bialix: thanks | 08:37 |
| igc | bialix: with rev 108 of bzr-windows-installers, the command to run is ... | 08:38 |
| igc | build.py installers --standalone-only | 08:38 |
| * bialix nods | 08:39 | |
| * bialix has pyqt 4.7.0 as well | 08:39 | |
| === radoe_ is now known as radoe | ||
| lifeless | thumper: https://edge.launchpad.net/codewiki | 09:19 |
| * igc dinner | 09:35 | |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| lifeless | vila: this, file a bug | 09:57 |
| lifeless | *thus* | 09:57 |
| lifeless | and yes, hydrazine for now, I think | 09:57 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| 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:19 |
| awilkins | ezod, update again (presuming you did an update to -r -2 to get to N) | 14:22 |
| 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:23 |
| ezod | `bzr heads` doesn't return anything | 14:25 |
| ezod | oh | 14:25 |
| ezod | bzr heads --dead does | 14:25 |
| awilkins | ezod, find your revision and pull that | 14:26 |
| ezod | revid is email-timestamp-string | 14:26 |
| ezod | ok cool, will try | 14:27 |
| awilkins | bzr pull -r revid:<blah> | 14:27 |
| ezod | awilkins: thanks, seems to have worked :) | 14:28 |
| c_korn | hello, how can I fix this error ? http://pastebin.com/XVcmjnWg | 15:01 |
| awilkins | c_korn, You need to upgrade the remote repository | 15:03 |
| awilkins | I believe there's a button in LP for that | 15:03 |
| awilkins | Or take a local branch that isn't rich-root | 15:05 |
| 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:11 |
| 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:12 |
| vila | yeah, that's the idea ;-) | 15:13 |
| vila | by the way, have a look at bug #489179 | 15:13 |
| ubottu | Launchpad bug 489179 in bzr "log file -v misses some revisions" [Low,Confirmed] https://launchpad.net/bugs/489179 | 15:13 |
| vila | jam: not for the bug itself, bug look at revno 4081.2.2 with qlog | 15:14 |
| 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:15 |
| jam | daggy shouldn't affect numbering | 15:16 |
| c_korn | awilkins: ok, I think I found the button. | 15:18 |
| c_korn | this is it I think: http://www.ubuntu-pics.de/bild/50919/screenshot_001_4B7Mnw.png | 15:19 |
| 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:20 |
| jam | vila: so what am I looking at wrt 4081.2.2 ? | 15:36 |
| jam | vs log file -v ? | 15:36 |
| 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:37 |
| 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:38 |
| vila | jam: ha, right, twice, I've been tricked by qlog for the other case but it's right here :-) | 15:41 |
| 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:45 |
| 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:49 |
| Lo-lan-do | Hi all | 15:53 |
| jam | morning Lo-lan-do | 15:53 |
| Lo-lan-do | jelmer: I think I found a race condition in bzr-svn the hard way :-( | 15:56 |
| jelmer | Lo-lan-do: hmm? | 15:59 |
| Lo-lan-do | Someone did an svn commit just as I was starting pulling a branch onto my bzr checkout | 16:00 |
| 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:01 |
| 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:02 |
| Lo-lan-do | Okay, I removed revprops, uncommitted and pulled again, and now I'm fine again. | 16:14 |
| jelmer | Lo-lan-do: his changes interrupted your push of a serie of revisions? | 16:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| ubottu | Launchpad bug 515850 in bzr-svn "Revisions added while a commit is happening are ignored" [High,Triaged] https://launchpad.net/bugs/515850 | 16:19 |
| Lo-lan-do | Sounds like exactly that, indeed :-) | 16:20 |
| Lo-lan-do | Sorry for the interruption. | 16:20 |
| tyarusso | I know this is an odd request, but does anyone have a side-by-side technical comparison of bzr against RCS? | 16:23 |
| jelmer | Lo-lan-do: np, it is an important bug to fix | 16:31 |
| === deryck is now known as deryck[lunch] | ||
| * 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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 | 16:36 |
| === salgado is now known as salgado-lunch | ||
| 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:05 |
| tyarusso | This there a way to give each versioned file a description? For instance "Config file for MySuperCoolProgram". | 17:06 |
| 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:07 |
| RobOakes | For example: http://server/repo/subdir? | 17:08 |
| jelmer | yeah | 17:09 |
| jelmer | provided subdir doesn't exist yet | 17:09 |
| RobOakes | Oh, that worked great. Thanks! | 17:09 |
| 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:16 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| msmith | hello everyone, i have a question about bzr-svn on debian | 17:26 |
| msmith | when installing on debian using apt-get i get the following: | 17:28 |
| 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:29 |
| msmith | is there a repository i can add to my sources.list that would contain an updated version? | 17:30 |
| Peng | msmith: Yes, unless the repository is out-of-date too. | 17:31 |
| Peng | Don't have a link right this second, though. | 17:31 |
| 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:32 |
| 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:35 |
| 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:36 |
| msmith | ok, thanks. i'll try to follow that path and scream for help if i fall off a cliff | 17:38 |
| === deryck[lunch] is now known as deryck | ||
| === beuno is now known as beuno-lunch | ||
| === salgado-lunch is now known as salgado | ||
| === zini1 is now known as zini | ||
| === IslandUsurperAFK is now known as IslandUsurper | ||
| 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? | 18:25 |
| === beuno-lunch is now known as beuno | ||
| rellis | Is there a way to get a commit history for a particular user with bzr? | 19:34 |
| krisives-gearbox | http://superuser.com/questions/128540/bazaar-merge-identical-files | 19:42 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:56 |
| krisives-gearbox | One issue with that strategy though | 19:58 |
| krisives-gearbox | I want to end up with 2 bzr repos | 19:58 |
| 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:00 |
| krisives-gearbox | I probably have that wrong | 20:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| vila | "Whatever works" he said :) | 20:07 |
| krisives-gearbox | Randomly, is there a way to tell `cp` not to copy a specific directory in a recursive? | 20:08 |
| vila | krisives-gearbox: randomly: cp everything somewhere, delete the offending dir, cp the result ? | 20:10 |
| krisives-gearbox | good idea | 20:10 |
| 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:11 |
| 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. | 20:12 |
| jelmer | jam: what's this history db thing you're working on? | 21:27 |
| jam | jelmer: caching the dotted revno / merge sorted graph | 21:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| jelmer | jam: what's the status on your pack collection work, is it ready to use in its current form? | 21:40 |
| jam | not yet | 21:41 |
| jam | I got distracted by this | 21:41 |
| Peng | We need to get you to collaborate with yourself from an alternate universe to get both done at once. :) | 21:43 |
| jelmer | jam: ok | 21:47 |
| pyMynx | anyone there? ^^ | 22:08 |
| Peng | Possibly! | 22:09 |
| krisives-gearbox | Thanks again for the help vila | 22:18 |
| 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:22 |
| === salgado is now known as salgado-afk | ||
| lifeless | https://code.edge.launchpad.net/~lifeless/bzr/commit/+merge/22920 | 22:23 |
| lifeless | jam: ^ | 22:24 |
| 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:27 |
| === mwhudson_ is now known as mwhudson | ||
| pyMynx | I'm pushing a folder to a server | 22:28 |
| pyMynx | but the folder on the server is empty after push | 22:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| lifeless | sure, I can add one. | 22:34 |
| 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:36 |
| Peng | pyMynx: lp:~bzr/bzr-push-and-update/trunk WFM | 22:37 |
| pyMynx | other way to create workingtree on server? :( | 22:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| Peng | pyMynx: Did you name it "push_and_update"? | 22:46 |
| 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:47 |
| Peng | yay | 22:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| pyMynx | Peng: I'm sorry for being a pain :) | 22:54 |
| 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. | 22:55 |
| 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:01 |
| pyMynx | ok thanks | 23:02 |
| pyMynx | on it! | 23:02 |
| pyMynx | Peng: nightmare :| no module XMLSerializer | 23:09 |
| mwhudson | jelmer: +0000 vs -0000 ? argh! | 23:37 |
| 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:38 |
| jelmer | yeah, it seems inconsistent | 23:40 |
| jelmer | committing manually I can only get it to write +0000 | 23:40 |
| mwhudson | boo :/ | 23:46 |
| mwhudson | another revprop then? | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
