/srv/irclogs.ubuntu.com/2008/08/27/#bzr.txt

jamjust to mention, it seems to say that it needs "libsvn" but that isn't going to be installed00:00
jamSo perhaps it doesn't install dependencies of Build-Deps ?00:00
jamSo you have to explicitly enumerate all of them?00:00
james_wah lpia00:00
jamI don't quite understand why it wouldn't complain on ~hardy, but maybe the packages already exist there?00:01
james_wsubversion hasn't built on lpia in Intrepid00:01
jamjames_w: well, it also failed for amd6400:01
james_wso it can't install the packages00:01
james_wwith the same error?00:01
jambut it could be the same reason00:01
jamjames_w: essentially00:01
jamhttp://launchpadlibrarian.net/17103816/buildlog_ubuntu-intrepid-amd64.bzr-svn_0.4.11-1%7Ebazaar1%7Eintrepid_FAILEDTOBUILD.txt.gz00:01
james_wthe packages are there for amd64, so it shouldn't be the same00:01
jamjames_w: well, it did fail, but I see what you mean from "rmadison" the packages *are* available for amd6400:03
james_wstrange it has built on lpia, but rmadison doesn't list them00:03
james_wand it built ages ago, so it shouldn't be archive skwq00:03
james_wskew even00:03
jamI prefer skwq00:05
jamI think that is the root cause00:05
jonnyde1vreixo: regarding signing commits -- you can find information here: http://bazaar-vcs.org/ConfiguringBzr00:05
james_wheh :-)00:06
LaserJockdoes anybody know of any docs on how one might use looms with packaging?00:06
james_wLaserJock: I don't think there are any yet00:06
vreixojonnyde1: The main doubt I have is how to choose the key used to sign00:06
james_wLaserJock: the NoMoreSourcePackages page gives an idea00:06
jonnyde1it is chosen by your configured bazaar identity00:07
vreixosure? and it takes the email into account?00:07
jonnyde1it must be exactly the same as used in your key00:07
jonnyde1yes, AFAIK00:07
vreixoI've tried bzr sign-my-revisions and it uses a different key00:08
vreixomy identity is bzr whoami, no?00:08
jonnyde1yes, it is00:08
james_wit uses your default key I thought00:08
james_wI think there was a bug opened on this the other day00:08
LaserJockjames_w: hmm yes, that does have some ideas on workflow. It seems a bit complicated though00:09
jonnyde1maybe it's the default key... but I think I've read somewhere that you should have the right whoami00:09
jonnyde1in fact, I'm doing it like this and it works....00:09
jonnyde1but try to set it as the default key in your keystore00:10
vreixook00:11
james_wLaserJock: complicated where? perhaps we can do better?00:12
james_wor just overall?00:12
jonnyde1vreixo: make sure you've set the whoami identity like: "Your Name <your.name@host.com>"00:13
vreixojonnyde1: I have00:13
vreixoI had00:13
jonnyde1ok00:14
vreixojonnyde1:  $ gpg --list-keys00:14
vreixopub   1024D/1635CB33 2008-02-2000:14
vreixouid                  Vreixo Formoso <vformoso@udc.es>00:14
vreixo...00:14
vreixopub   1024D/66A4028A 2008-08-1600:14
vreixouid                  Vreixo Formoso <metalpain2002@yahoo.es>00:14
LaserJockjames_w: maybe complicated isn't quite the right word00:14
vreixo$ bzr whoami00:15
vreixoVreixo Formoso <metalpain2002@yahoo.es>00:15
vreixobut it uses the other key!00:15
LaserJockjames_w: maybe it's not very "packaging-like" but more "vcs-like"00:15
jonnyde1so maybe it's indeed an issue with the default key....00:15
james_wLaserJock: yeah, I guess. Does that apply to the "wrapped" command set outlined as well, i.e. "new-patch fix-2345" or whatever it is called?00:17
LaserJockjames_w: I don't think that's on NoMoreSourcePackage, but that might help00:18
jonnyde1vreixo: in your ~/.bazaar/bazaar.conf you should find your identity set by whoami, I think...00:19
james_wLaserJock: ah in the HCT stuff, so it's not quite the same thing00:19
vreixo jonnyde1: it is right00:19
james_wLaserJock: at the moment we are trying to build a set of VCS "primitives" that will allow us to model the workflow, and then we can evolve a set of tools on top that are more task-oriented for packaging.00:20
james_wLaserJock: or, that's my hope anyway :-)00:20
LaserJockmhm, makes sense00:20
james_wso loom does this quite well I think00:21
jonnyde1vreixo: sorry, but that's the only advice I can give you... for me it worked right from the start...00:21
james_wperhaps topgit is better, but I think it's too complicated, and the task-oriented stuff will be harder00:21
=== mario_ is now known as pygi
vreixojonnyde1: tanks anyway, I will try with the deafult key idea00:22
LaserJockjames_w: do you know of any efforts for sort of an inbetween flow, between no VCS and NoMoreSourcePackages?00:22
LaserJockjames_w: it seems like such a huge jump00:22
jonnyde1good luck! :)00:22
james_wLaserJock: well, NoMoreSourcePackages is kind of two things, there's the "No more source packages" part, which I hope we will reach by getting to a point where we don't want them in our workflow as they are more hassle than they are worth00:23
james_wLaserJock: for the command set parts it will be an evolution to get those commands (possibly there will be several tools along the way), so it won't be an instant thing00:24
LaserJockjames_w: right, at some point we just replace, debuild -S && dput *_source.changes, with bzr push00:24
james_wLaserJock: and in the mean-time you can avoid loom and use bzr if you like, handling .diff.gz as the diff between two branches, which is much the same as you have now.00:24
james_wLaserJock: I hope so00:25
LaserJockjames_w: one of the parts that's kind of making me wonder is that, in Ubuntu at least, many developers only upload a package once or twice00:26
LaserJockso I wonder what advantage all this workflow/vcs work is to them00:27
james_wI'm not sure00:28
LaserJockin essence, many developer may not care at all about history, feature branches, tracking patches, etc.00:28
james_wbut if it makes their work easier and more efficient they will "care"00:28
LaserJockwhich makes NoSourcePackages possibly turn into a burden00:28
LaserJockwell, that's the part that I'm trying to get my head around00:29
LaserJockhow would it make their work easier and more efficient?00:29
james_wso an example from an hour or so ago00:29
james_wI had a sponsorship request open on lvm2 for a while, and in the meantime there were uploads to Ubuntu00:30
james_wI had the packages in bzr from dogfooding my work, so I spent a couple of minutes importing the new uploads (which no-one else will have to do)00:30
james_wI ran bzr merge, and got everything merged, with a couple of merge conflicts00:31
james_wthen committed and regenerated the request00:31
LaserJockok, so in that the advantage was bzr's merging abilities00:32
james_wso, I noticed the problem and ran one command to merge the work. It was done using history, not 2-way, I got easier to deal with conflicts (in my opinion), and had the history there in e.g. annotate to work out what to do.00:32
james_wif I hadn't I would have had to have download the new packages, generate a diff, apply that, got .rej files, worked out what had gone on from reading changelogs00:33
james_w*I* think that is so much easier00:33
james_wI know that I'm very comfortable with bzr though00:34
LaserJockit is, although i'm not sure how often we get conflicts00:34
LaserJockmost of the time it's just download new package, re-apply patch, re-debdiff00:34
james_wbut when it's not it's much harder00:35
LaserJockfor sure00:35
james_wwe have e.g MoM to automate this for merges00:35
LaserJockhmm, MoM-as-bzr would be interesting00:36
james_wwe could build similar tools for all of the cases where things fall down, like the above case of the archive moving underneath you, or we could build on top of a framework that allows to more easily do it for anything00:36
LaserJockif we could just grab current Debian version, branch from MoM and work on the merge all in a bzr repo that'd be pretty sweet00:36
james_wand gives the same benefits whether we are in the easy case or the hard case00:36
lifelessjam: did you want a standup?00:36
james_win phase 2 we will have Debian in bzr, so it would be simply "bzr merge lp:debian/unstable/gcc" or something00:37
james_wand MoM can do dry runs and publish results in the same way as now00:37
LaserJockjames_w: sound quite interesting00:39
LaserJockcan bzr make "quiltable" patch series? not sure if my terminology is quite right there, I don't use quilt00:39
james_wwe need to do better at explaining these benefits, as I don't think many people see where we can go with this00:39
james_wyeah, it could, there's a couple of ways00:40
james_wit may be a good way to go.00:40
LaserJockI wonder how good collaboration with Debian would go00:40
james_wone problem at the moment that merging debian/patches/* really screws you up, we need to improve that somehow.00:40
james_wso converting to bzr on the way in, and then converting back when building the source package would be one way00:40
LaserJockI'm kinda getting to the point where perhaps just sharing patches rather than debdiffs or DVCSs is the way to go00:41
james_wso something we can easily do is provide easy ways to spit out various sorts of patches, so you would fix something in bzr, and then spit out e.g. a dpatch to forward to Debian. We can then improve on that00:42
james_wthought generating plain patches is good for 90% of cases or more00:42
LaserJockhmm, yeah00:43
LaserJockif I were to be able to look at what the Debian maintainer is using (say dpatch) and then run something like gen-patch --dpatch that'd be really cool00:44
lifelessif you use looms to manage the Ubuntu branch, thats totally doable00:45
lifelessprobably 20 lines of python to add a command to do that to loom00:45
LaserJockrockin'00:45
lifelessjames_w: so the gtk one, what do you need from me? I can't upload to main..00:46
james_wis -gtk main?00:47
james_wnope, universe00:47
lifelessoh huh universe00:47
lifelesscan't you upload it then ? :)00:47
james_wnope00:47
lifelesshmm, syncs are meant to be done by archive anyhow00:47
james_wlifeless: yeah, but I needed a sponsor to ACK it for the archive admins to look at it00:48
james_wwell, confirm it and subscribe ubuntu-archive00:48
lifelessI've commented on both00:48
lifelesshmm, am I still in sponsors00:48
james_wyou don't need to be in the team as far as I know00:49
LaserJockI'm in ubuntu-{universe,main}-sponsors if you need anything00:49
james_wthanks LaserJock00:49
lifelessLaserJock: if you could process https://bugs.edge.launchpad.net/ubuntu/+source/bzr-svn/+bug/26165300:49
ubottuLaunchpad bug 261653 in bzr-svn "Please sync bzr-svn 0.4.11 (universe) from Debian experimental (main)" [Wishlist,New]00:49
lifelesshttps://bugs.edge.launchpad.net/ubuntu/+source/bzr-gtk/+bug/26164500:49
ubottuLaunchpad bug 261645 in bzr-gtk "Please merge bzr-gtk 0.95.0-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed]00:49
james_wLaserJock: would you be willing to ack a couple of main sync requests as well then please?00:49
lifelessI don't do enough syncs to keep it all paged in, I was just checking the current procecss00:49
lifelessjames_w: where is the bzr 1.6 sync request?00:50
LaserJockjames_w: depends on how many ;-)00:50
james_wlifeless: bug 26163600:50
ubottuLaunchpad bug 261636 in bzr "Please sync bzr 1.6-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/26163600:50
lifelessLaserJock: 300:50
lifelessLaserJock: I think thats all00:50
james_wLaserJock: that one, and bug 261644 to go with it00:50
ubottuLaunchpad bug 261644 in bzrtools "Please sync bzrtools 1.6.0-1 (main) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/26164400:50
lifeless400:51
lifeless:P00:51
james_wthen bzr-svn sync for universe, and bzr-gtk merge00:51
LaserJockok, so bzr-* ? :-)00:51
james_wjelmer has already done all the lesser plugins and got acks, so with these four we get most-recent everything, with everything compatible00:52
lifelessjam: ping00:52
jelmerlifeless, if you feel like uploading bzr-search, maybe that can make it into intrepid as well00:52
jelmeralmost made it earlier but got rejected because of incorrect debian/copyright00:52
lifelessjelmer: garh00:53
lifelessjelmer: url me up I guess00:53
lifelesspackaging is so 1960's though00:53
jelmerlifeless, http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=bzr-search00:54
jelmerlifeless, are you calling me oldfashioned? :-P00:54
lifelessdamn thats a fugly url00:54
* jelmer gives lifeless a gentoo ebuild00:54
lifelessshudder00:54
james_wjelmer: don't you want sponsor-packages?00:55
lifelessjelmer: is the package anywhere that doesn't suck arse?00:55
jelmerlifeless, try http://mentors.debian.net/debian/pool/main/b/bzr-search/ instead00:55
lifelessjelmer: cause that site wants me to log in 'first'. IDIOTS00:55
jelmeryeah, sorry, I gave the link inside the login area00:56
lifelesshmmm, I'm not in the most forgiving-of-the-universe modd today00:56
jelmerlifeless, http://mentors.debian.net/debian/pool/main/b/bzr-search/ should work better00:56
lifelessoh yay00:56
jelmernow what ? :_)00:56
lifelessstupid robots.txt defeats wget00:56
lifelessmanually copying urls now00:57
lifeless*this* is why I don't sponsor much00:57
lifelessits about 4 billion times harder than it should be00:57
jelmerwell, at least you *can* sponsor00:57
* jelmer just lost another application manager00:57
lifeless!00:58
lifelessare you a MOTU yet?00:58
jelmerno - I don't do much Ubuntu stuff, I always work in Debian and then request syncs00:58
lifelessjelmer: because its so much easier, apparently ? :)00:58
jelmerit is, once the initial package is in. I probably wouldn't be using or developing for Debian if that hadn't made it00:59
LaserJockif you've got packages that can be just synced it's nice to just maintain in Debian00:59
lifelessjelmer: there will be a delay01:01
lifelessI need to update my sid01:02
lifelessoh01:02
lifelesscrud, other machine01:02
lifelessETOOHARD01:02
lifelessthe packaging looks ok, though the reference export command is stale01:03
LaserJockbzr done01:04
jelmerlifeless: It's mainly there to make ftp-master happy, I'll add a get-orig-source target later01:05
lifelessjelmer: also it looks like you've got a bzr 1.5 deps, but it requires 1.601:05
lifelessBuild-Depends-Indep: bzr (>= 1.5~)01:05
jelmerlifeless, it only build-depends on 1.5, the actual dependency is on 1.601:05
jelmerI'll fix the build-dep, it should be harmless though01:06
lifelessThat needs a comment if its deliberate, or not to be different01:06
lifelesswell, the sid chroot is updating01:06
jelmerlifeless: Yeah, I'm fixing it here; it's cosmetic though01:06
lifelessbe quite a while01:06
jelmerlifeless, thanks for looking into this01:08
lifelessjelmer: I'm about given up on it; another headache and it will be ETOOHARD - too much to do01:11
jelmerlifeless: :-(01:15
lifelessthere is _so_ much beauracracy involved its insane01:16
lifelessyou'll still have to wait for NEW01:16
jelmerplease don't get me started01:17
lifelesswe practice crunchy shell security as far as copyright honoring goes01:17
jelmerNEW's been pretty quick in the last few weeks01:17
lifelessit may catch a bunch of stuff; but as all debian/copyright does is duplicate whats in the package already, it doesn't help anything01:17
jelmer...  and if a new upstream release adds weird stuff, there's no review at all from ftp-master01:18
lifelessthats what I mean by crunchy shell01:18
jelmerah01:18
lifelessonce you're in, you're in.01:18
jelmerWhen I think of shell, I think of "shell script"01:18
lifelessits a standard description of certain risk management techniques01:19
jelmerah01:22
jelmerwell, nothing's perfect, but it can indeed be pretty frustrating at times..01:22
jelmerlifeless, any luck getting it to build?01:23
lifelesschroot still updating01:24
LaserJockbzrtools done01:35
LaserJockbzr-svn done01:38
lifelessjelmer: sorry, I'm going to have to leave bzr-search01:40
jelmerlifeless, :-(01:41
jelmerbeuno, ping01:42
lifelessthe reason I do nearly everything I do do for ubuntu is source uploads01:42
LaserJockjames_w: you need to remember to update the Maintainer field in debian/control :-)01:42
lifelessonly takes a few minutes fighting pbuilder + debbuild & deps etc and my tolerance for incoherent toolchains is exceeded01:43
james_wLaserJock: damn, thanks for catching it.01:43
james_wLaserJock: I presume you don't need a new debdiff?01:43
LaserJockjames_w: no, I just run update-maintainer01:43
james_wcool, thanks01:44
LaserJockhowever, it does dep on the newer bzr01:44
LaserJockso I'm not sure if I should upload until that's sync'd01:44
LaserJockI guess I could just let it fail and then somebody can hit the retry button :-)01:45
jelmerlifeless, I can provide you with a pre-built package... :-)01:48
lifelessjam1: are you back ?01:48
lifelessjelmer: I can't upload that01:48
jelmersiretart: Could you perhaps sponsor bzr-search?01:48
jelmerlifeless: Why not?01:49
lifelessjelmer: thou shalt not upload binaries thou didst not build thyself01:49
james_wLaserJock: it should just auto-depwait shouldn't it?01:49
LaserJockjames_w: well, one would hope but I'm not 100% positive01:50
james_wor at least manual depwait01:50
jelmerlifeless: Why? Yes, I could've tampered with the binary but once the package is in sid, I can upload newer versions without intervention.01:50
james_wI'd suggest just getting it in, and then fixing if we need to, but you're the sponsor01:51
lifelessjelmer: its part of the stuff I agreed to when I became a DD01:51
jelmerlifeless: hmm, ok01:51
LaserJockjames_w: uploaded01:52
james_wLaserJock: great, thanks a lot01:52
LaserJockjames_w: though I sort of disagree with the "no longer uses a patch system" part. It still build-depends on dpatch even though it's not using it ;-)01:52
james_wtrue, I saw that afterwards01:52
james_wit's already committed upstream though, so it's not a long-term problem01:53
LaserJockbut without a patches/ it's just an extra dep01:53
james_wyup01:53
LaserJockanywhere, there's a complete bzr set01:54
LaserJockwhich makes me happy, i got to do more than complain about things being out of sync :-)01:54
james_wperfect, that puts Intrepid in good shape01:54
jelmerwell, the packaging spree was nice while it lasted02:00
jelmeruni starts again on friday, so I guess I'll changing the remaining ones back to RFPs for now02:01
markhI think I'm suffering branch overload.  One of my working trees is 4 branches away from its ultimate upstream...02:01
lifelessmarkh: you might like looms02:01
lifelessjelmer: how far did bzr-git get?02:01
markhI'm not sure I need *more* bzr workflow options at this point... ;)02:02
jelmerlifeless: I ended up working mostly on fixing bugs in bzr-svn02:02
markhI only just use shelve for the first time the other day - wonderful :)02:02
jelmerlifeless: bzr-git can now do clone/pull from git -> bzr02:02
lifelesscool02:02
lifelessdoes git keep a hot refcount for each hash?02:03
lifelessor is gc a global operation ?02:03
jelmerlifeless: also, tags can be set, info works and log works again02:03
jelmerafaik its global but I'd have to check to be sure02:03
james_wyou mean does it walk the heads to find unreferenced objects?02:04
lifelessjames_w: if it has a list of heads that is always accurate and race free, then it has a hot refcount for objects with refcount 002:09
lifelessjames_w: doing race free with loose objects will be quite a challenge though02:09
james_wah, I see02:09
james_wI think02:10
james_wI don't know how it does that02:10
jdongMay I make the suggestion for more user-friendly release notes?02:39
jdongI think users are interested in something more readable than the release notes format, which seems to appeal to developers of bzr more.02:39
jdongI'm thinking something in the form of Ubuntu's tours would cater better to end users (highlighting major improvements, new features, etc)02:40
lifelesswould you like to help write something like that? That would be really nice02:41
jdongI'd certainly be glad to contribute to such an effort02:42
lifelessI think we'd be happy to have release notes in such a form, as long as its contributed :)02:43
jdong:)02:44
lifelessjam1: ping03:12
abentleyjelmer: Why did handle-patch stop being a command?03:48
abentleyjelmer: And have you noticed it's full of tabs?03:48
frikazoydHowdy04:00
frikazoydAnyone around who can answer a quick question?04:03
bob2go for it04:06
frikazoydCool04:06
frikazoydSo, I discovered Bazaar through a friend, and was thinking about moving my development/playtesting team to it.04:06
frikazoyd(Mod team)04:06
frikazoydI tried installing 1.6, and everything I can find says TortoiseBZR comes with the windows install.04:07
frikazoydHowever, I don't see the TortoiseBZR shell integration, even after a reboot.04:07
frikazoydIs there anything special I have to do to get it working?04:07
frikazoydAhhh, I think I found my answer.  I'm using XP 64, and an included sub-readme says that the 64 doesn't work due to packaging issues.  I guess that's my problem.04:09
frikazoydTakes asking it before you figure it out I guess, heheh.04:09
bob2http://bazaar-vcs.org/WindowsDownloads doesn't seem to mention tortoisebzr, though04:12
lifelessmarkh: what's needed for win64?04:13
markhpy2.6 on windows04:13
markhapart from that, not much ;)04:13
markhbashing the required extension modules into shape04:13
lifelessis py 2.6 not on windows yet ?04:13
markhpywin32 is already there04:13
markhearlier py versions use MS compilers with sucky/no support for 64bits04:14
markhpy2.6 is using the latest MSVC and makes life easy04:14
markhpy2.5 on windows is at the same place on windows as any other os roughly...04:14
markh2.604:15
markhstable in my experience04:15
markhFWIW, a 64bit native exectable can often see 15%ish perf improvement over running a 32bit version of the exe on the 64bit os.04:16
markhfrikazoyd: ah, sorry, I didn't see your comments.  Yes, 64bit toirtoise will need to wait a little while04:17
markhthere is a hacky work-around04:18
frikazoydOk04:18
frikazoydWell I don't mind running the 32 bit04:18
frikazoydto be honest04:18
frikazoydbut the 32 bit installer didn't install tortoise bzr04:18
markhIIRC, executing "\windows\syswow64\explorer.exe /separate" should start a new 32bit version of explorer that works with toirtoise04:18
frikazoydfor some reason04:18
frikazoydor it just isn't showing up04:18
markhdidn't install, or didn't register?04:18
frikazoydAh, ok04:18
markhright - it registered as a 32bit extension04:18
frikazoydWell it said it registered tortoise in the installer04:19
frikazoydAAAhhhhhh04:19
markhonly 32bit executables will see it04:19
lifelessgotta love that old MS style04:19
frikazoydand my explorer is 32 bit04:19
markhhrmph04:20
lifelessthunk layers? We're tired of that, WoW blew chunks, lets not do that again04:20
frikazoydYeah, I'm not a fan.  However, my hands are tied since I'm a Source modder04:20
lifelessfrikazoyd: oh cool.04:20
markhwindows supports 32bit processes via a "wow" (windows on windows) layer, which is basically a thunking playground.  It *does* support loading 32bit binaries into 64bit executables04:20
markhwhich is what COM and shell extensions are all about04:20
frikazoydHm04:21
markhbugger04:21
lifelessmarkh: yes, YHBTHANDHTH04:21
markhs/*does*/*does not*/04:21
frikazoydHrm, the workaround didn't let me see the shell extension04:21
frikazoydah well, I don't mind using command line04:21
lifelessmarkh: the 16-32 bit wow did allow OLE to work across boundaries IIRC04:21
frikazoydthe bottom line is I have a ton of playtesters who will complain about using a command line, but if they can use the extension in 32 bit windows I can just write a batch script for the ones that run 64 bit.04:21
lifelessmarkh: which is what my mini-troll was about04:21
markhlifeless: yess, out-of-process COM can be marshalled04:22
markhwe are inproc04:22
lifelessmarkh: can't you just set an oop registration anyway?04:22
lifeless:)04:22
markhfrikazoyd: I admit I've never tried that workaround on 64bits - I will before the next release though.  This whole problem will go away once we move the shell extension code to c++ anyway04:23
frikazoydOkay04:23
markhlifeless: shell extensions only work in-proc unfortunately04:23
frikazoydWell I've played with installers quite a bit, so if you need a hand let me know.  But I'm not much of a windows programmer, so I don't know how much help I'd be in general.04:23
frikazoydThough I'm not bad with C++ itself04:24
markha .msi would be good :)04:24
markhbut we need to sort out other internal packaging issues before we take on a different installer04:24
frikazoydok04:24
lifelessman04:24
lifelessI so love how COM is inconsistent04:25
lifeless'its totally generic' -> except that its not04:25
markhheh - for sure.  Plenty of scope for tuning etc.04:25
markhbut the rate of calls made to shell extensions and the blobs passed around would make an out-of-proc system struggle04:26
lifelessmarkh: thats no reason not to -permit- it04:26
lifelessmarkh: (also, they could fix the interface to do less work more sanely)04:26
markhAll the interfaces would need custom marshallers iiuc04:26
markhand there are *lots* of them04:26
markhall the interfaces are defined in terms of c++ structs, not nice little COM variants etc04:27
markhits really just using COM as a "plugin" mechanism in some ways :)04:27
markhI'm not defending things, just trying to add perspective ;)04:27
lifelessmarkh: remember, I'm an ex-cygwin-core dev :P04:30
markhlifeless: ahh, never knew that :)04:30
lifelesssearch for robert collins cygwin :)04:30
* markh wonders what else has can come up with by putting various words after "robert collins"...04:32
lifelessbeware my evil clones04:32
lifelesstheres a rc writes for dr dobbs journal04:32
lifelessand another in a uk python-using research job04:33
markhoh - another as a porn star I see! ;)04:33
lifelessoh really? cool04:33
lifelessnow I can get a real hackergotchi04:33
lifeless:P04:33
fullermdThey're everywhere these days.  I think there's one stealing my name too.04:35
em1good morning04:35
em1cant donwload openerp's source by running 'python bzr_set.py',04:37
em1wait long time and no file is downloaded04:37
em1last time i can download all files04:37
em1but this time after installed symlink plugin, it become calm down very much04:38
em1seems that python run into a dead loop or no connection for ever04:39
em1it do create a directory, but no files04:39
bob2what is bzr_set.py?04:39
em1bob2, it is from lp:openerp04:39
bob2the 'openerp's default branch on launchpad doesn't contain openerp?04:40
em1do you means the trunk?04:41
bob2yes04:41
em1yes, it contains only two files04:41
em1one is bzr_set.py, other is a readme04:41
bob2bizarre04:42
em1readme file say need run bzr_set.py to fetch source04:42
em1bob2, what?04:42
bob2that's a bit baroque04:46
em1bob2, do you have advice to detect where it go wrong?04:48
bob2well, it will take a while04:48
bob2you could just try checking out the code manually04:48
em1how to do manually?04:49
bob2look in the file, bzr_repository lists the urls it is fetching04:49
bob2just "bzr branch" them04:49
em1.bzr\repos...\upload have a big file sized of 27M, is it ok?04:53
=== jam1 is now known as jam
jamlifeless: pong04:56
lifelessjam: hey05:00
lifelessjam: trade you a review of log [rather than a comment] for a review of btree ? :)05:00
jamsure05:01
em1i report a bug justnow, dont know if it is a bug:  Bug 26173305:06
ubottuLaunchpad bug 261733 in bzr "crashed after i intall symlink" [Undecided,New] https://launchpad.net/bugs/26173305:06
jamlifeless: btw, you asked for me to factor out the common code, but the loops really aren't the same.05:17
jamI'm I misunderstanding what you are asking me to refactor?05:17
lifelessoh05:19
lifelessthe add_node method looked like a extract from the base class, verbatim05:19
jamlifeless: no, self._nodes contains different things in each05:20
jamBTree doesn't need to track absent nodes05:20
lifelessok05:20
lifelesshave a look, see if there is enough to do something common05:20
lifelessotherwise ok05:20
jamI could probably extract the "_check_node" into a helper05:21
em1until now, the source is downloaded but not over, why so slowly, my adsl bandwidth is 2mbps05:31
lifelessem1: what url is the source coming from?05:34
em1that is lp:openerp05:36
bob2http://bazaar.launchpad.net/%7Eopenerp/openerp/package-script/annotate/9?file_id=bzr_set.py-20080708192342-trihj558tjhh9549-2, line 2205:37
bob2(lp)05:37
lifelesshave you logged into launchpad?05:39
lifelessin bzr05:39
em1me?05:42
lifelessyes05:42
em1no, i dont know how to log into lp05:43
lifelessok, then it will be doing http requests05:43
lifelessit should stream fast05:43
lifelessif its not, its likely a ISP problem; e.g. a broken intercepting proxy05:44
em1i try bzr antherproj, it finished quickly05:44
em1all project do host on the same computer?05:45
mwhudsonyes05:45
em1maybe because of openerp have very much codes to download05:45
em1for nearly 2 hours, it still not finish downloading05:46
em1not wonder there is a virus somewhere05:46
jamWell, http://bazaar.launchpad.net/~openerp/openerp/package-script/.bzr/repository/packs/05:48
jamis only a few K05:48
jambut that is just the packaging?05:48
bob2yeah, it then scripts branching 5 other ones05:49
lifelessjam: just sent you a toy06:03
gourdidn't know that python is considering bzr..today on reddit http://pyside.blogspot.com/2008/08/quick-hgbzr-timings.html06:32
gouris this another 'apples & oranges' benchmark?06:33
LaserJockI wonder why 1.6 is often slower than 1.506:35
LaserJockalthough the branch time looks like a big improvement06:35
RAOFjml: Oooh.  Is bzr upgrade over bzr+ssh substantially faster than sftp?06:38
gourclone time is showstopper, at least, it was for ghc evaluation06:38
RAOFReally?  It's essentially a one-off time, though.06:39
jmlRAOF: I don't have any data on that. My guess is "yes".06:39
jmlRAOF: because there should be fewer roundtrips and much less data being transferred.06:39
lifelessLaserJock: memory06:39
lifelesstheres a peak memory use bug in 1.606:39
gourRAOF: yeah, it is, but although having many advantages over candidates, it was ruled out due to speed - mostly based on 'clone'06:40
lifelessupgrade over either will be the same06:40
jmlmy understanding of clone time is that 'time to branch' and 'time to build working tree' should be measured separately.06:40
RAOFjml: Given bzr+ssh requires a server-side copy of bzr (IIUC), theoretical maximum performance would seem likely to be very fast.06:40
jmllifeless: it just uses vfs methods?06:40
gourjml: right06:40
lifelessyes06:41
vilajam: I'm already working on it, but thanks for the reminder07:01
* jml types 'bzr record "hello robert"'08:02
lifelesshello jml08:08
jml:)08:08
jameshapparently the command is useful for something08:09
lifelessjamesh: why 4 the troll?08:11
jameshlifeless: I see value in recording the thread name -> revid state at a point in time, but the current plugin doesn't really do much with those records08:12
lifelessjamesh: thats true08:13
lifelessjamesh: really need 'merge' implemented08:13
jameshand I guess it'd be nice if it happened automatically at relevant points in time08:13
lifelessI'm less sure about that; 'bzr push' doesn't do an implicit commit08:14
lifelessI think it would weird people out majorly if it did :)08:14
jameshperhaps committing to the top thread would be worth recording08:14
lifelessI'd like to have merge working robustly before looking at that sort of automation08:14
jameshor recording every commit08:15
jamesh(that is slightly dubious, due to possible conflicts in higher threads)08:15
lifelessright08:15
lifelessor in lower threads for that matter08:15
jameshso I guess my complaints are (1) it is one more thing to remember to do during development and (2) it provides no obvious benefit right now.08:20
lifelessjamesh: I agree with both08:27
lifelessbut trolling doesn't get merge written08:27
lifelessthere are benefits right now, in that is does allow revert-loom08:27
lifelessbut its not a great benefit08:27
jmland it's made less by the fact that the only time I remember to do a record is when I'm about to push.08:38
jmlwhich basically means "before meals".08:39
siretartjelmer: bzr-search uploaded, but I wasn't able to commit my changes: http://paste.debian.net/15695/ - what's going on here?08:41
techtonikDoes bzr support branching from subtrees of original repository or I always need to copy whole directory tree when branching?08:41
lifelessthumper: always full tree08:41
siretartjelmer: and I uploaded to experimental, since it seems to depend on bzr 1.6, which is not available in unstable08:41
lifelesstechtonik: ^08:41
thumperlifeless: morning08:42
techtoniklifeless: Thanks for quick reply. But if the whole tree is too big to copy and I need only a small part (plugin) to work on - what should I do?08:45
james_wsiretart: you would need a --rich-root-pack repo for the local checkout of bzr-search, as the alioth repo is in a rich-root format08:45
james_wsiretart: would you be available for an upload of builddeb later today?08:46
lifelesstechtonik: you can skip copying all the deep history by using branch --stacked, or checkout --lightweight; if the current tree is simply too big; well buy a new hard disk?08:46
lifelesstechtonik: we have a planned feature to help, but its planned not implemented08:46
lifelesshi thumper08:46
lifelessok, bzr-search rockage :)08:49
lifelessrobertc@lifeless-64:~/source/baz/log$ time ./bzr log ../bzr.dev -m "robert" > /dev/null08:49
lifelessreal    0m12.357s08:49
lifelessrobertc@lifeless-64:~/source/baz/log$ time ./bzr log ../bzr.dev -m "\brobert\b" > /dev/null08:49
lifelessreal    0m4.706s08:49
siretartjames_w: sure08:51
james_wsiretart: great, thanks08:51
techtoniklifeless: The current tree is about 900Mb (lp:codeblocks) - not much for an HDD, but too much for my internet limits.08:51
lifeless900MB for the working tree? or the full history?08:52
techtonikWorking tree only/08:53
bob2they eclipsed eclipse!08:53
lifelessjeepers08:53
lifelessthats...insane08:53
techtonikActually 450 Mb as it is SVN checkout, but still too much.08:53
bob2how on earth is it all in one branch?08:54
bob2the full linux binaries are 20MB08:54
siretartjames_w: just tell me what is the up-to-date branch I should upload. and do you want it for unstable or experimental?08:54
techtonikSVN import - that is.08:55
james_wsiretart: experimental and intrepid, if you don't mind, to save a sync delay.08:55
james_wsiretart: I don't have a branch yet though, I still have some work to do.08:55
siretartjames_w: ah, okay.08:56
techtonikUFO:AI repository with media files takes even more than 1Gb08:56
techtonikI've got a problem with bzr merging. Since I didn't want to copy whole repository I just recreated directory structure, manually copied files for the plugin from the main trunk and started my own branch.08:58
techtonikNow I can't merge changes from the main trunk into my branch, because they do not have any common ancestors in bzr.08:59
techtonikWhen I supply some "-r BASE..LAST" revision argument to merge, then bzr comes up with a lot of conflicts. http://pastebin.com/m75a6caa609:05
techtonikI wonder how can I resolve them? The ones about unversioned directories, for example.09:06
bob2well, you could start over and re-add everything with the same id's as are used in the trunk09:07
bob2but that's not a huge amount of use09:07
techtonikDoes that mean I will lose all the history?09:13
bob2which history?09:14
bob2well, yes, either way09:14
techtonikOk, I suppose it is the only way. So, how can I add everything with different id's so that the subsequent merge will be successfull and will not pull all other files from main trunk into my subtree?09:36
lifelessjelmer: done a 1.6 bzr search release09:37
jelmerabentley, was required to be able to register it as a mime type handler09:55
jelmersiretart, thanks!09:55
jelmerlifeless, ok09:55
techtonikSo, Bazaar doesn't have partial checkouts? =/10:09
lifelessthe answer hasn't changed from earlier :)10:09
lifelessits planned10:10
lifelessnot implemented10:10
awilkinsls10:10
awilkinsOops10:10
lifeless['.', '..']10:10
awilkinsIs there a plugin that will snapshot a workspace of multiple trees so you can check out the same thing elsewhere?10:11
lifelessmultiple trees?10:11
awilkinsMultiple branches or checkouts10:11
lifelesslike nested, or same project or ...?10:11
awilkinsSay - an eclipse workspace containing multiple branches10:12
awilkinsThe workspace is not a branch, but the projects inside are10:12
siretartawilkins: check 'config-manager'10:13
awilkinsI knew I'd seen something10:13
awilkinsIsn't that your project, lifeless?10:15
lifelessyes10:18
lifelessbut its about trees, not branches :P10:18
lifelessawilkins: probably needs some love to do what you want, but yeah config manager is what you'd want for N branches of the same project10:31
awilkinsIt's more 1 branches of N projects10:32
lifelessthat sounds more like nested trees to me then10:32
awilkinsNot in the same tree10:32
lifelesscm still applicable10:32
awilkinsSiblings in a container10:32
awilkinsLike an eclipse PSF file10:33
awilkinspsf == cm recipe10:33
awilkinsIs it just a straight file?10:33
awilkinsOr is it versioned so you can do things like merge it from other workstations?10:34
lifelesscm doesn't care10:34
lifelessyou can version if if you want :P10:34
awilkinsWould it handle switches?10:34
awilkinse.g. you switch the branch on your workstation, you sync cm recipe on laptop, cm switches to same branch ?10:35
lifelessit has a switch command10:38
lifelessits not well maintained cause I've been putting it of for nested trees10:38
awilkinsFair enough10:38
lifelessbut I may need to give it some love10:38
lifelessanyhow, yeah poke at it10:38
Peng_beuno: Shouldn't Loggerhead's /static/ URLs generate Expires headers and stuff?10:47
beunoPeng_, maybe. I don't know that much about http voodoo10:48
lifelessPeng_: they all should; mwhudson is working on it10:50
Peng_lifeless: Yeah, I just saw that bug. Maybe I should add a comment to remind him about the static stuff?10:50
lifelesssure10:51
Peng_Wow, changing that is actually a one-line patch.11:03
Peng_Is there any point to GPG-signing a very trivial email, with an untrusted key? :)11:20
EarthLionerm i have an issue where bzr doesn't seem to be recognising 2 new files that have been created11:37
lukswhich command specifically?11:38
EarthLionwhen i commit it says there are no changes11:38
EarthLionwhen there clearly are11:38
luksand diff shows changes?11:38
luksor status11:38
EarthLiondiff shows no changes11:38
lukser, wait11:38
beunomaybe they're ignored?11:39
luksthey are new files, did you add them?11:39
luks`bzr add`11:39
EarthLionnope they were created by a web application11:39
luksthen you need to add them first11:39
EarthLionexpression engine saves new templates as templates11:39
luksbzr add path/to/file11:39
EarthLioni thought it did that automatically though?11:40
Peng_It does not11:40
luksno, it doesn't11:40
luksbzr status should also tell you about unknown files in the working tree11:40
EarthLionthanks i can see the file now11:41
EarthLioncan you set it up to automatically add new files?11:41
luksI think there was a patch to add an option to bzr commit to do that, but it was rejected11:41
EarthLionthat seems v.odd that it isn't there11:42
EarthLioni presumed it did that automatically11:42
EarthLionin a project files are always being added...11:42
luksI don't know about others, but I usually have files in the working tree I don't want to version11:42
EarthLionso I have to manually add all new files?11:42
luksyou can just run 'bzr add'11:42
luksit will add all unknown files11:43
EarthLionah ok thanks luks11:43
EarthLionexcellent thanks for the concise information :)11:43
lukshttp://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/45138 is the ML thread, btw11:45
EarthLionthanks a lot :)11:48
=== gour is now known as gour|lunch
techtonikIf I can't make a partial ceckout, can I download a part of a tree without version history?12:29
lifelessI think my patch allowing 'export target branch/subdir' is in 1.612:30
techtonikdoesn't seem so12:32
techtonikbzr export xxx http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk12:33
techtonikbzr export xxx http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk/src12:33
techtonikbzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk/src/".12:33
techtonikBazaar (bzr) 1.612:33
techtoniklifeless: Is there other way to get some subdir (which is not branch) from repository without redownloading whole repo or manually downloading separate files one by one from web interdace?12:44
lifelesstechtonik: well, bzr.dev should do bzr export xxx http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk/src12:45
lifelessand there will a new loggerhead sometime soon that can export subdirs12:46
lukstechtonik: is it really a problem to download ~60MB of data?12:46
techtonikluks: Yep. 1.5$ for every 60Mb is too much if you are on ADSL and 3.5 hours is too long if you are using Dial Up or GPRS modem12:55
luksouch :(12:55
luksand I thought my connection was expensive12:56
=== gour|lunch is now known as gour
jamvila: Just to make sure, Robert is discussing a "trie" not specifically a "tree". http://en.wikipedia.org/wiki/Trie13:06
jamI haven't gotten through all of your email yet, though.13:06
vilajam: hmm, did I missed the *whole* picture again ? AIUI he want to use hash tries or B+ trees, but in both cases the inventory is still represented as some sort of tree, so I think hash trees (as I called them) are still more or less in the subject even indirectly13:09
vilawtf ? plugin.gtk.test prompting me during selftest ???13:09
vila (55, 'select/poll returned error') now, some have decided to die *today* :)13:16
vilas/some/some bugs/13:16
lifelessvila:  a trie is a radix tree13:21
jamvila: Just to discuss my understanding of his proposal... lifeless proposes that you can use "apply_delta" to update a hash trie without needing to look at the whole tree13:21
jamSo if you already have one built13:21
lifelessvila: a hash trie is variation of a trie13:21
jamyou can build the next without doing O(tree)13:21
jamlifeless: are you even really proposing a "hash trie" ? I thought it was just a trie using paths and file_ids as the keys13:22
jamnot the hashes of those13:22
vilayet the proposal want to address some performance issues for operation that are O(tree) instead of O(changes) which, has we discussed in London can be addressed with hash trees (as *I* called them).13:23
vilaIf I'm wrong on that point, then forget the related remarks in my review :)13:23
lifelessjam: I'm investigating the properties of several designs13:23
lifelessjam: one is a radix tree of the hashes of the file ids13:24
lifelessone is a plain radix tree13:25
lifelesson the full paths of the entries13:25
lifelessanother is directory based, with large directory decomposed into internal trees13:26
jamvila: I think what you call "hash tree" lifeless calls "recursive validators" which he plans for any of them13:30
jamCHK == content hash key13:30
jamSo the individual pages are referenced13:30
jambased on their content hash13:30
jamlifeless: so why use hash(file_id) just to get a more even distribution?13:31
vilajam, lifeless: CHK haaa, then the document needs to define the term13:31
jamvila: "validator(x)" is generally just secure_hash(x)13:31
jamhe mentioned it earlier13:31
jamI don't know if it missed the last draft13:31
jamWho just built and uploaded the windows installers?13:32
jamDid Markh do it overnight?13:33
markhnot over my night ;)13:33
jamI just see "TommiVainikainen" updating the wiki, which isn't a name I recognize13:33
markhover my day tho, yeah13:33
jamthanks markh13:33
jamJust make sure to make a note of it :)13:33
markhI did rc5 and noone complained it didn't work for them, so I figured it was good to go!13:33
markhwhere? :)13:34
LarstiQhehe :)13:34
markhI'm afraid noone pointed out a process I should follow - martin just said "upload it there" :)13:34
markhhi LarstiQ!13:34
LarstiQheya markh13:35
jammarkh: well, sending an email to the list is reasonable, updating http://bazaar-vcs.org/Download and WindowsDownload13:35
LarstiQmarkh: I've still got to figure out that list of music for you, it's pending, sorry :/13:35
jamalso, I linked a bug to you yesterday13:35
jamsomeone filed a complaint that the installers took longer than a day to build...13:35
LarstiQwhat?13:35
LarstiQas in, start the build, and wait for a day?13:35
LarstiQOr are they complaining the installers are uploaded a day after the release?13:36
LarstiQIf so, pssh.13:36
jambug #26161413:36
ubottuLaunchpad bug 261614 in bzr "Stand-Alone version for 1.6 for Windows" [Undecided,New] https://launchpad.net/bugs/26161413:36
lifelessjam: hashes give a homogenous fan out, which is good13:37
jamnot sure whether to mark it Invalid because it isn't a bug, or Fix Released because we have the installers13:37
jamI went with Invalid for now13:37
markhjam: so I'm in trouble for not doing it fast enough, or not waiting long enough to follow the correct processes? ;)13:37
jammarkh: well, I feel like reporting a bug for it, versus just an email/request is a bit ... excessive13:37
jammarkh: I just didn't have anything alerting me that it happened13:38
markhjam: right, yeah, I agree - but you know users - we have nothing better to do than serve them :)13:38
markhyeah - we probably need a slightly more formal process, and I'd be happy to follow it13:38
markhI wasn't sure exactly when you "turned the crank" for the release etc.  For the sake of a day or so, we could probably coordinate more closely next time13:40
jammarkh: Well "doc/developers/releasing.txt" is my checklist for tarballs, and ".../ppa.txt" is what I use to make debs13:40
jammarkh: I'm fine with a 1-2 day turnaround13:40
lifelessjam: also, it caps the depth of the keys, tries have a property of O(1) for a given key set - its a high, but constant number of steps (read every bit in the key)13:40
jamWe could certainly create a "windows_installer.txt" file and put it in there13:40
lifelessso capping the key length reduces the constant13:41
jamlifeless: It would be interesting to do comparisons between hash(file_id) and file_id13:41
jamas one allows a bit of grouping13:41
jamWhich may or may not give locality of reference13:41
jamalso, bzr's default algorithm for file ids is13:42
jamNAME-DATE-RANDOM-COUNTER, where DATE-RANDOM is fixed for everything during one "bzr add"13:42
jamwhich probably means you just end up with a long string that doesn't help, because NAME has already messed up your common prefix13:42
lifelessjam: right13:45
lifelessjam: thats one reason I am looking at hashed file ids as keys13:45
jamYeah, I wonder if the 1/256 fan-out is going to be optimal in all cases13:46
lifelessa CHK pointer13:46
lifelessa kind13:48
lifelesssay another 4 bytes13:48
lifelessso 45-50 bytes per pointer13:48
jamwould you use binary/hex/base64 for the serialized key?13:49
lifelessfor now, lets say yes13:49
jam:)13:49
gimakeradd benchmarking of different trie-types, and will have lots of fun benchmarking a billion different combinations :p13:51
lifelessjam: say 50bytes per ref13:51
jamlifeless: and 256 refs per node?13:52
lifeless256 way fan - 12K13:52
jamlifeless: 256-way fan out... gives 16.7M in 3 levels13:53
jamits what we saw with b-trees13:53
lifelessjam: yes13:53
jamit takes a *lot* of keys to hit a 3rd level13:53
lifelesswhich is fine13:53
jam(and there it is more like 100-way)13:53
lifelessbecause we don't need 256 way fan out13:53
lifelesswhere there are no children, we trim13:53
lifelessa wider prefix in a node - less fan out (counter-intuitive, but true)13:53
jamlifeless: Sure, but I wonder if hash() is going to tend to enforce it13:53
abentleyjelmer: I don't understand why the shell script I provided wasn't sufficient to register it as a mime type handler.13:54
lifelessonly the very root nodes will be so dense; and it may be we want to optimise for a smaller root page size13:54
jamit makes me *wonder* if we would rather have a node pointer for [a-c] => THIS_PAGE13:55
jambut then it isn't strictly a radix tree13:55
lifelessOTOH 12K per commit isn't impossible to handle with, if we also are compressing those nodes13:55
lifelessjam: we need a well defined canonical form13:55
lifelessjam: well, look closely at the fan out rules; I think we cam make the description more clear with a bit of effort13:56
lifelessI think the current rules may be very pleasantly surprising13:57
lifelessalso, give that toy I sent you a spin13:59
jamwill do14:02
Nghow does one upgrade a remote branch, specifically one on launchpad? I've tried all the URL variants I can think of, lp:, bzr+ssh://bazaar.launchpad.net, etc. to no avail14:02
jamNg: with 1.6 or bzr.dev, lp: or bzr+ssh: should work (earlier ones you need to use sftp://bazaar.l.n)14:03
jamHowever, once you've upgraded it leaves a 'backup.bzr' directory14:03
jamwhich may be in the way for another upload14:03
jams/upload/upgrade14:03
Ngjam: is that roughly a suggestion that I not do it? ;)14:03
jamNg: well, you have to delete the backup.bzr directory, and LP doesn't give you an easy way to do it14:04
jamYou can use an sftp program that lets you do recursive delete14:04
jamNg: I highly recommend that you do, just letting you know where it may fail14:04
jamrather than telling you "do X" and having you come back with "X failed"14:04
Ngjam: fair enough, thanks :)14:05
lifelesshitchhiker will let you delete it now14:05
lifelessas the launchpad sftp server doesn't work with lftp recursive delete14:06
Nghitchhiker?14:07
lifelessyes14:07
jamNg: it is a program written by abentley to act like an "sftp/bzr+ssh/etc" client by using the bzrlib Transport code14:08
Ngah14:08
jamnot a particularly *good* ftp/sftp client, but the *best* bzr+ssh:// client available :)14:08
abentleyjam: :-)14:09
jamabentley: wasn't that even your tag line14:10
jamabentley: does hitchhiker use get_transport() such that "lp:foo" should work, as well as ":parent" ?14:10
abentleyjam: Okay...14:10
abentleyabentley: :-)14:10
abentleyjam: Yes, lp: specs and all plugins should work.14:11
vilahmm, bitten by bug #225020, hard. Even bzr.dev exhibits the bug14:19
ubottuLaunchpad bug 225020 in bzr "pycurl reports "select/poll returned error"" [High,Confirmed] https://launchpad.net/bugs/22502014:19
jamvila: bite back14:19
jamor apt-get remove pycurl14:19
jamI've been happily using your urllib code for a long time now14:19
vilaI intend too, this bug seems hard to reproduce and pycurl have been removed from pqm for lack of reproducing and fixing it14:20
vilas/too/to/14:20
jamwell, IIRC spiv could reliably reproduce it just by installing pycurl14:20
vilaRegarding urllib/pycurl I doubt we can just drop https certificate validation14:21
viladepending on the branch I run selftest the first failing test is different...14:22
vilaand of course running the tests alone make them pass14:23
jamvila: well, I would just create a http stress test14:29
jamjust GET the same URL repeatedly14:30
jam(It certainly sounds like a plain bug in pycurl)14:30
jamvila: though it may be a POST issue14:30
vilathat or leaked sockets14:31
jamwell, all of the reported bugs are about POST14:31
jamAnd I could imagine that POST code gets less testing than GET code14:31
jamYou might also consider that these may be a 404 on POST14:32
jamas a side question, if you have a DFA, do you usually represent that as a 2D table in memory? Or do you collapse it somehow14:36
vilajam: is that for me ? what is a DFA ?14:37
jamDeterministic Finite Automata14:37
jamor automaton14:37
jamI was reading about Trie's and they link over to DFA's14:37
jamhttp://en.wikipedia.org/wiki/Deterministic_finite_automaton14:38
jamI've heard about them before, but never dug deep into them.14:38
lifelessuhm14:40
lifelessthere are a bunch of DFA representations14:40
lifelessin parsing its  often a graph14:41
vilaWell, on my last project I write an automaton generator for simple ones so we went for a 2D table in flash memory (read-only) but when automaton grow you need to compress the table (which is most of the time very sparse)14:41
vilaotherwise most of the time I use them through scanner and parser generator which compress the tables heavily14:42
lifelessvila: used antlr?14:43
vilalifeless: never had the occasion but it was on my radar :-) I used [f]lex/yacc/bison heavily though and a bit of perl Parse:RecDescent module in the end14:44
vilaI even port lex/yacc sources on DOS and Mac OS 7 (or 6 ?) :D14:45
lifelessI've written a dirstate antlr3 grammar14:45
lifelesswell, most of14:45
vilalifeless: and your feedback is ?14:47
lifelessmmmm14:48
lifelessC runtime is immature14:48
lifelessrest is out on judgement still14:48
lifelessoh, and I hate lexers14:48
lifelesslexers are the universes way of punishing us for parses that are too slow14:48
jamlifeless: so, of course, you need to answer the question... is it *faster* ?14:49
vilaHmm, I've seen parsers suffer really badly from bad scanners, but that's more the exception than the rule IME14:49
vilaof course it depends of the tool chain but the one I used the most (C/C++ by Flex) were ok (including parsers for > 1M files)14:51
vilai.e the parsing itself was in the noise compared to the associated semantics14:51
lifelessvila: my point is I don't like writing scanners14:51
lifeless'0-9' for instance can match far to much14:51
lifelessfoo0114:52
lifelessvalid path14:52
vilalifeless: ok, that's different then, but years of perl experience tend to help here too :)14:52
lifelessalso matches 01 if you don't force a whitespace in the scanner14:52
lifelessworse, consider whole numbers vs ints14:53
ryanakcaI'm having trouble checking out an lp branch, could someone help me out please? bzr branch lp:ubuntu-dev-tools gives http://ryanak.ca/~ryan/bzr-error ... Someone gave me a fix to this a few months ago, but I never jotted it down :/14:55
jamryanakca: you have bzr-svn installed, and a containing .svn directory14:59
lifelessvila: I'll reply tomorrow14:59
jamso the branch command seems to be trying to re-use it14:59
vilalifeless: are you still in AU, your hours seems unusal ?15:00
jamBut there is something odd in that bzr-svn is actually unable to open your .svn directory15:00
ryanakcajam: svn: warning: '.' is not a working copy15:00
jamryanakca: short answer, disable bzr-svn15:00
jamlonger answer15:00
ryanakcajam: how can I disable plugins during a command ?15:01
jambzr branch --no-plugins bzr+ssh://bazaar.launchpad.net/~ubuntu-dev ...15:01
jam(the problem is the 'lp:' prefix is a plugin as well)15:01
jamryanakca: I would also try to figure out why we can't open "/home/ryan" as an SVN working directory, as then you won't have to workaround this all the time.15:02
ryanakcajam: ah. ok, thanks. But why would it try to open /home/ryan if I'm trying to branch in /home/ryan/work/ ?15:02
jamryanakca: We search for a possible shared repository in containing directories15:03
jamyou could do "bzr init-repo ~/work" and then we would find that one instead15:03
Freakyhm, is 1.6-rich-root supposed to be more bloaty than rich-root-pack?15:03
jam(or just bzr init there if you didn't actually want to shared downloaded data)15:03
ryanakcajam: thanks15:03
jamFreaky: I'm pretty sure the stored form is supposed to be the same.15:03
jamIt is more of a config flag15:04
FreakyI'm doing a bzr upgrade, the original .bzr is 211MB, the new one is 259MB and still growing after 85 minutes15:05
Pieterit's creating a new pack file for your upgrade15:06
Pieteryou can delete the old files afterwards15:06
Pieterso the growth is just temporary15:06
Freakyah, repository is 48MB, repository.backup is 210MB15:07
Freakyand it should grow to be roughly the same?15:07
Pieterwho knows?15:08
Peng_Freaky: Probably. Wait and see. :)15:08
Freakybe waiting a long time then ;)15:09
gourbzr-svn-0.4.11 is released?15:37
jamgour: yes, it should be in the ppa15:37
jamI don't think jelmer gave an official announcement15:38
jambut he created the tag and published it to debian15:38
jamand had me publish it to bzr-ppa15:38
* gour is on archlinux15:40
gourgreat...no more svn :-)15:40
jamthere should be a tarball somewhere15:40
gouri got it. ta15:41
gourit's here http://samba.org/~jelmer/bzr/bzr-svn-0.4.11.tar.gz15:41
rockyhere's a question, is it safe to create a rich root repo on one box, do a bzr-svn co of a remote svn url beneath that repo, and then copy that repo to some other machine and use it there?15:55
LarstiQrocky: I _think_ so, but I haven't tried it.15:56
luksit's perfectly safe, people are using even repositories on usb sticks and more them between computers15:57
luks*move15:57
rockyoh yeah? now that's interesting15:57
gourjelmer: thank you for 0.4.1116:13
* gour is doing his first fetch of svn repo via bzr-svn16:14
gourhmm bzr crashed - http://rafb.net/p/dkYRIG77.html16:15
gouram i doing something wrong?16:16
jelmergour: no, that should work fine16:17
jelmergour: did this work previously?16:18
gourjelmer: dunno. my first fetch from the repo and first use of bzr-svn plugin16:19
jelmergour: please file a bug16:20
gourjelmer: for bzr?16:20
jelmergour: bzr-svn16:20
gourok16:20
jelmergour: it could be a serverside thing as well, google's svn may not like how we're using it16:21
dleeThis just happened to me; wondering if it's worth worrying about:16:22
dleeBZR 1.5:  Repo created in Unix, checkout in Windows.  One file name ends with a space!  (It came from a cab file!)16:23
Peng_ok?16:23
dleeIt works in Unix, but in Windows, you can't check out properly:  there's always a "Remove file" in bzr diff.  You can't merge into it because it's an unresolvable uncommitted change.16:23
dleeI think Windows ignores the trailing space on file creation.  Interestingly, bzr diff shows "remove file" but no diff contents.16:24
dleeIf you actually remove the file, you get the listing of contents per usual.16:24
gourjelmer: https://bugs.launchpad.net/bzr-svn/+bug/26187816:24
ubottuLaunchpad bug 261878 in bzr-svn "bzrlib.plugins.svn.core.SubversionException" [Undecided,New]16:25
dleeTheory:  This means Windows matches the file during that process too; it just can't make the name match.16:25
jelmergour: thanks16:26
dleeI'm guessing bzr could ignore the trailing space in the repo name and make everything work on Windows, but I may not know what I'm saying. :)16:27
jelmerdlee: you should be able to just remove the trailing whitespace in unix16:28
jelmerdlee: commit then and then update in windows16:28
jelmerdlee: I think bzr should be refusing to check out files with trailing whitespace in their name on Windows, just like it should refuse to check out files with certain other characters in their names16:29
dleeTrue, but the file set is auto-generated (and regenerated) by a process.  Basically I'm using Bazaar to version-control the contents of a set of files (including cab file contents) produced by someone else.16:29
dleeBut yes, I can write a sort of post-processor that de-spaces the nasty filename before commit.  It's a cab, for Windows anyway, so no one will care. :)  Let me know if you want a bug filed on this or if it's just too obscure to worry about though.16:30
jelmerdlee: please file a bug16:30
dleewill do.16:31
jelmerdlee: We do plan on warning when you add a file that can't be checked out properly on other platforms16:31
=== rocky1 is now known as rocky
abentleyjelmer: We don't deliberately refuse to check out any files on Windows, and I don't think we should.16:32
jelmerabentley: some files simply can't be checked out on Windows because of their name16:33
abentleyjelmer: I think we should handle it as a conflict.16:33
jelmerabentley: that's an interesting thought16:33
abentleyjelmer: So we check them out with a different name, and tell the user what we did.16:33
abentleyjelmer: That way, Windows users (who are the only ones likely to care) can fix such problems themselves.16:34
jelmerabentley: yeah, that's nicer indeed than having to go back to unix to fix it there..16:34
rockyjelmer: as you might imagine, bzr-svn over dial-up is useless ;)16:35
rockythat is, push commits and the like to the remote svn using bzr-svn over dial-up is useless ;)16:36
dleeAs a rule (and with CVS, Svn, and Bzr all three), I find the process of juggling between Unix and Windows in a single project to be loaded with problems.  In Bazaar, files and folders get .moved mostly.  But I use Bazaar for a few irregular purposes, like backing up/post-versioning web sites...16:36
jelmerabentley: I would really like to see a warning system on unix rather than forbidding certain characters16:37
abentleyjelmer: I'd like that, too.16:37
jelmerrocky: yeah, I wouldn't attempt to do that (yet)16:38
jelmerrocky: what will help is having only one svn repo per project16:39
LarstiQthere was a time when you couldn't even make a branch of something that had a revision with 'con.txt' in the inventory16:39
jelmerLarstiQ: ah, the good old days16:39
LarstiQyes, very fun.16:39
rockyjelmer: well ... that's mostly what i do, but that "project" sometimes has several sub-projects16:39
jelmerrocky: yeah, the subprojects is what I mean16:39
LarstiQabentley: excellent idea on the conflict for such a situation btw16:39
rockyjelmer: having to create a separate svn repo for each subproject is a bit overkill on these projects i'm working on ;)16:40
jelmerabentley: oh btw16:40
jelmerabentley: bzr-handle-patch.sh relied on something being in "/home/abentley"16:40
jelmerabentley: so instead of fixing the shell script I just changed it to use python directly16:41
abentleyjelmer: Removing a command seems like a rather extreme way to fix that.16:42
jelmerabentley: wasn't the command just for internal use (by mime-type handlers and the like) anyway?16:43
jelmerabentley: If it's not, I misunderstood and we should look at reintroducing it.16:44
abentleyIt's not just for internal use.16:44
=== lamont` is now known as lamont
jelmerabentley: Sorry16:45
* gour is fetching from another svn repo16:45
jelmergour: works better this time 'round?16:45
rockyjelmer: what happens if i bzr co a remote svn folder into my bzr 1.6 rich root repo ... and then *check out* that same folder from the bzr rich root repo into some local place? i mean, what happens when i committ locally?16:46
jelmerrocky: afaik bzr won't let you create a checkout of a checkout, but I'm not entirely sure16:46
LarstiQit will.16:46
abentleyIt was meant to be a regular Bazaar command.  With a wrapper because mime-type mechanisms are so primitive.16:46
gourjelmer: it is still copying...unfortunately, i've cinelerra's rendering job in the background, that's why it's going slower16:47
loxshello. as far as I see from the docs, bzr uses only one .bazaar config directory per project. Does this mean that I cannot use only a part of the repository (let's say only the trunk/)?16:47
gourloxs: part of repo or one branch?16:48
jelmerLarstiQ: what will it do when you commit though?16:49
loxsgour, I want to co and up only the trunk (the main branch) on my server, so that it is always up to date. But I don't want the document root there... only the trunc/myapp/ directory, because that must be in the python path16:50
jelmerloxs: ah, you mean partial checkouts16:51
jelmerloxs: (in bzr terminology)16:51
loxsyes jelmer, that's very easy with svn16:51
jelmerloxs: they're planned but not implemented yet16:51
gourloxs: see http://bazaar-vcs.org/SharedRepositoryLayouts?highlight=(layouts) as well16:52
loxsnah, gour, you say I need a different philosopy ;) i like this kind of answers :)16:55
rockydon't suppose anyone has a script lying around that will produce a commit msg that includes a listing of all the merged rev msgs that you're about to commit?16:56
gourloxs: sure, every tool has its own recommended workflow. i came from darcs and cannot expect bzr to work in the same way :-) that's why i 'm adjusting to bzr. same with different programming languages...it is nnot smart to write C in Python, nor Haskell in Python, but use Python idioms in Python16:57
awilkinsrocky: The log contains that information anyway, why do you noe extract it the other way (iterate the sub-revisions of your merge revision)16:58
dleejelmer:  Filing as a comment to bug 391816:58
ubottuLaunchpad bug 3918 in bzr "bzr can be caused to error with filenames containing newlines" [High,Confirmed] https://launchpad.net/bugs/391816:58
jelmerdlee: thanks!16:59
rockyawilkins: well, this is merging using bzr-svn which i don't think will track that info in the svn log16:59
awilkinsrocky: Fair do's16:59
jelmerrocky: if you have svn 1.5, bzr-svn will store the merge info16:59
jelmerrocky: that should allow svn ("svn log -g" I think) to display what revisions were merged17:00
rockyjelmer: i had to revert to svn 1.4 unfortunately ... mostly because of setuptools inability to deal with svn 1.5 properly17:01
loxshm, gour, you say it's possible to have project root being my python package root, and have the branches as directories? o_O... that's new :)17:01
jelmerrocky: how do you mean?17:01
jelmerrocky: setup.py in bzr-svn?17:01
rockyjelmer: no... i'm a python coder by trade ... and i use setuptools to manage all of my own projects... well setuptools cannot deal with svn 1.5 checkouts properly with any release version of setuptools17:02
gourloxs: i wasn't speak about python projects, but in general considering how svn projects are laid out17:02
jelmerrocky: ahh, ok17:03
rockyseveral bugs17:03
rockyjelmer: and stuff where setuptools will inspect files and auto-include them with "setup.py sdist" fails with svn 1.5 checkouts17:03
* Odd_Bloke is getting http://paste.ubuntu.com/40944/ when trying to run bzr-svn trunk with bzr.dev.17:03
Odd_BlokeAnyone know what's going on?17:04
rockyso, i've reverted back to svn 1.4.6 since i have no good reason to upgrade to 1.5 anyways17:04
jelmerOdd_Bloke: you need to build bzr-svn17:04
jelmerback in ~30min17:05
Odd_Blokejelmer: Anything more than 'make'?  Because I've done that.17:05
Odd_Blokejelmer: NM, there were a number of weird interactions going on.17:08
Odd_BlokeFixed now. :)17:08
loxsI read quite a lot and I still wonder is it a good idea if my working tree root and my python package root are the same directory.... and then put branches in subdirectories?17:54
luksperhaps a terminology issue, but by 'working tree' you mean a bzr working tree?17:55
loxssure, luks17:55
lukswell, technically you can't put branches inside branches, but I don't think it's a good idea17:56
lukser, can, not can't17:56
luksif this is a single package, it should be a single branch, IMO17:57
loxswell, the reason I want this thing is because of the lack of partial checkouts in bzr17:57
luksand normally you put the package into a directory, not to the root17:57
loxsand I want to update my server from the repository17:58
luksloxs: but then you lose the ability to checkout the whole package17:58
luksif it's split into several branches17:58
loxsI dont' get what you mean17:58
lukslet's say you have myproject/trunk and myproject/trunk/subpackage where both trunk and trunk/subpackage are separate branch17:59
loxsno, i don't want that18:00
luksthen by running "bzr branch myproject/trunk" you will not get myproject/trunk/subpackage18:00
luksoh18:00
loxsI mean the following:18:00
loxsI want project/ to be the trunk/18:00
loxsand a project/branches/ subdirectory to hold the branches18:00
luksah, that's not a problem18:02
loxsi mean, that when my server checkouts the repository, it goes straight into the python path... and it works out of the box, because I co it in the python path18:02
loxsif there is project/trunk, then trunk is no more accessible as a python package18:02
luksI meant that project/trunk/ is a branch18:03
luksnot that you have a branch project/ with a directory trunk/ in it18:03
loxsI will not have a trunk/ directory at all... the root of the project will be the trunk18:03
loxsis it ok?18:03
luksyes, location of branches usually doesn't matter in bzr18:04
=== toytoy_ is now known as toytoy
loxsand do you think it is a good practice luks?18:06
luksloxs: well, I personally wouldn't put the package root to a root of a branch18:08
rockyare there any other deployments for bundle buggy out there other than the bzr one at aaronbentley.com18:08
luksbecause then it's harder for me to do setup.py and other things18:08
luks(if by package you meant a python package)18:09
luksah, yes18:09
loxsyou say  you would prefer to use setup.py and install from the repository instead of using the program from the repository directly?18:09
luksdepends on the situation, but I prefer all python packaged to have setup.py18:10
loxsit's a django site18:10
luksif you want to use the working tree for deployment, I'd probably just symlink it18:10
loxshm, yes, it's probably a good idea too...18:10
luksI don't know what's the usual layout of django projects18:11
luksbut I would be surprised if they had python files in the root directory18:11
loxsthe thing there is that there are quite a lot of non-python files that have to be used... html, css etc.18:12
luksthere must be templates, some static files, maybe some unrelated data files and scripts18:12
luksexactly18:12
loxsbut the main part is a python package18:12
loxsthat must be on the python path18:12
luksis this for develoment or production deployment?18:12
loxsdeployment18:13
loxsfor development there is a dev server that does'nt care where it is... it is run via a script from the project18:13
loxsbut for deployment the project is called via mod_python and it must be in the python path18:14
luksyou can modify sys.path from mod_python18:14
luksso I'd point it to the working tree18:14
loxsI know, but I sill prefer to have my project in site-packages18:14
loxsand I planned to have a cron job to sync the repository there18:15
=== gour is now known as gour|dinner
luksthen a symlink, I don't like the idea of mixing python code with data files in the same directory18:15
loxsyes, I'll probably go with a simlink18:15
loxsthank you for the conversation :)18:16
luksnp, I like having these kind of conversations :)18:16
loxsand what is your personal preference for a repository layout?18:17
loxsi read this http://bazaar-vcs.org/SharedRepositoryLayouts?highlight=(layouts) and can't choose :)18:17
luksI like a flat list of branches in the repository18:18
luksso repo/trunk/ repo/branch1/ etc.18:18
luksand separate repositories for separate projects18:18
loxsyou mean the good old svn style? :)18:18
luksno, svn does repo/trunk/ repo/branches/branch1/18:19
luksI don't like the branches/ directory18:19
loxsaha, I see18:19
loxsdoesn't it get quite cluttered then?18:19
luksI delete branches after they are merged, so it doesn't18:20
loxsI need some place where inexperienced "wannabeadeveloper"s make their own little chaos :)18:21
loxsso probably I'll go with something like developer/whatever he chooses/18:21
jelmerluks, where do you put tags then?18:40
luksjelmer: bzr tag :)18:40
jelmerluks, ah, I thought you were talking about your preferences for svn (-:18:41
luksI wouldn't dare to delete svn branches18:42
lukseven with the 1.5 merge tracking18:42
mptHeeeeeeelp ... I tried to upgrade my remote repository, but it hung because of bug 256757. Now that the remote server is updated to bzr 1.6, I've tried "bzr upgrade" again, but it reports "The branch format Bazaar-NG meta directory, format 1 is already at the most recent format", when I know it's not.18:43
ubottuLaunchpad bug 256757 in bzr "upgrade from <RepositoryFormatKnit1> to the newest format eats all my ram" [Critical,Fix committed] https://launchpad.net/bugs/25675718:43
jammpt: which branch18:44
mpt(After the previous failed attempt I replaced .bzr with the backup.bzr it had made when it started.)18:44
mptjam, no branch in particular, this is at the project level18:44
mptDo I need to do it for each branch separately?18:45
jammpt: sure, I was just hoping to poke at it and make sure18:45
jamis it somewhere I could get to it?18:45
jelmerjam, any chance you can comment on https://lists.ubuntu.com/archives/bazaar/2008q3/046309.html ?18:50
jamIt doesn't seem like enough of anything to really comment on18:51
jelmerjam: Ok, no objections to it though?18:54
jamNo specific objections, though your VCSMapping object is just information about the mapping, it doesn't do any actual mapping18:54
_stink_i'm trying to do 'bzr branch lp:sendoff', and getting an error: http://paste.ubuntu.com/40966/  This is with bzr 1.5.  Is there some kind of config problem that could cause this, or should I go to 1.6?18:56
jelmerjam: That's all implementation-specific, this is just infrastructure shared between bzr-git and bzr-svn18:58
jam_stink_: well, it looks like the ssh connection is failing. you could try: bzr branch lp:sendoff -Derror18:59
=== mw is now known as mw|food
jamwhich gives a  full traceback18:59
jelmerI wanted to check before I did any more work on this, since I was a bit surprised when my VirtualSignatureTexts patch was vetoed18:59
jamjelmer: well VST was an inversion of layering18:59
jamwhich was a bit odd18:59
jamFor your Mapping stuff, it doesn't seem like a problem, but it also doesn't seem to provide much yet19:00
jamso perhaps at least a little discussion about why you want to use it, and how19:00
mptthanks muchly for your help, jam19:00
jamnp mpt19:00
jamhappy to help19:00
_stink_jam: http://paste.ubuntu.com/40968/ for output with -Derror19:00
jam_stink_: what hapens if you do: "sftp bazaar.launchpad.net" ?19:01
jam(It at least seems like a ssh connection error)19:01
jamyou just have to use sftp because launchpad only allows bzr+ssh or sftp19:01
_stink_jam: http://paste.ubuntu.com/40969/ still publickey connection error.19:03
jam_stink_: you should be able to do "sftp -v"19:04
jamIt sounds like something between you and LP is preventing you from connecting19:05
=== gour|dinner is now known as gour
_stink_jam: ah, i think i know. just realized i had uploaded a separate ssh key for LP, and i'm not telling it which one to use.  i did this when i was just playing around. i think i can fix it now. thanks19:06
tethridgeif I have a branch on a server and I create a new branch from it.  Then I make a change to the new branch and "push" to the old branch can I assume that the old branch will be a copy of the new branch?19:15
tethridgeI'm not sure if that is an acceptable thing to do19:15
luksyes, it will be19:15
luksand if there is a reason why it can't be, bzr will complain19:16
luks(complain and not perform the push)19:16
tethridgethat's cool19:16
tethridgeI would like to think that it would work that way, but not all software "just works"19:16
=== tchan1 is now known as tchan
jaypipesjam: query window...19:28
=== emgent` is now known as emgent
pickscrapeWould I be right in thinking that bzr bundle is the same as bzr send without the mail client integration?19:36
james_wpickscrape: yes, you would19:40
pickscrapejames_w: thanks, it's just what I'm after :)19:40
luksI don't think it is19:41
abentleypickscrape: bzr bundle is a hidden command and may be removed at a later date.  "bzr send -o" is *also* the same a bzr send without the mail client integration.20:05
abentleyjames_w: Please encourage people to use bzr send.  There's nothing bundle can do that send cannot.20:15
pickscrapeabentley: ooh, I had actually looked for such an option in bzr send but for some reason completely missed that one... Thanks!20:20
abentleypickscrape: no problem.20:21
=== mw|food is now known as mw
jelmerabentley, do you have any idea what could be causing bug 203376 ?20:47
ubottuLaunchpad bug 203376 in bzr "traceback when merging an svn repo with a 'bzr join'ed branch" [Medium,Triaged] https://launchpad.net/bugs/20337620:47
abentleyjelmer: Which bzr version did you confirm it on?20:48
jelmercurrent bzr.dev and bzr 1.620:48
jelmerGood point, I'll put it in the bugreport20:49
abentleyjelmer: So, I would guess that two codepaths are causing the creation to be cancelled, but a creation can only be cancelled once.20:50
jelmerabentley: What could cause that though?20:51
jelmerabentley, the actual join worked fine and committing it also worked fine20:51
jelmerthe first merge of the joined branch after that fails20:51
jelmerthe merge would only change a file text, nothing else20:51
jelmerabentley, why would it need to call fix_root() in this case?20:52
abentleyjelmer: look, it's a bug.  If I'd expected it to happen, I'd have fixed it too.20:52
abentleyjelmer: We always call fix_root, for regularity's sake.20:52
abadger1999If there's any Fedora users here that would like to become Fedora packagers for parts of the bzr stack, I'll be happy to sponsor you and help to review your packages :-)20:53
jelmerabentley: I'm just trying to understand what's happening since I'm not very familiar with this code20:53
jelmerabentley: ah, ok20:53
abentleyfix_root should only have an effect when you've got a tree with two roots.20:54
abentleyJoin shouldn't give you a tree with two roots, it should make one tree's root into a subdir of the other.20:54
abentleyI suppose you could do conflicting joins.20:55
jelmerabentley: Thanks, that helps20:55
jelmerabentley: The problem is somewhere in fix_root, skipping it fixes the problem20:56
abentleySo that one tree claims that x is a subdir of y, and another tree claims x is a subdir of z.20:56
Odd_Blokeabadger1999: I'd suggest mentioning this on-list, if you haven't already.20:56
abentleyThat would cause merge to give you a tree with two roots.20:56
abentleyBut it's actually intended for the case where you're merging two unrelated trees.20:57
jelmerabentley: the problem appears to be that merging another branch whose root is not the root of the tree we're merging into breaks things20:57
jelmernot the root of the tree we're merging into, but present as regular directory in that tree20:58
abadger1999Odd_Bloke: I'll do that eventually.  It's much easier to mentor someone to be a good packager if they're active on IRC, though.20:58
abadger1999So I thought I'd start here.20:59
jelmerabentley: I think I know enough now anyhow to try and get this fixed20:59
jelmerabentley, thanks!20:59
abentleyjelmer: You're welcome.21:01
james_wjelmer: hey, did you send me your merge-upstream changes?21:16
jelmerjames_w, No, I requested merges in lp21:16
jelmerjames_w, I'm happy to send them to you as well if you prefer21:17
james_wah, I'm obviously not subscribed21:17
james_wI can look21:17
james_wI've just completely re-written the code though, sorry21:17
jelmerjames_w, where's your code these days?21:17
jelmerLast change I see here is from quite a while ago21:18
james_wyeah, it's been in flux for a long while21:18
james_wbzr+ssh://bzr.debian.org/bzr/pkg-bazaar/bzr-builddeb/2.021:18
james_wyour change will still apply, but have no effect, I haven't deleted the unused code yet21:19
james_wwow, you have been busy21:19
james_wso, you want it to degenerate to "bzr merge" sensibly, but do some other things as well?21:22
jelmeryeah, with all that packaging I did I used bzr-builddeb a lot :-)21:22
jelmerjames_w: Yeah, basically "bzr merge" and figure out the new Debian upstream version string21:22
james_wI'd like to leave these out of this release21:23
james_wit's already huge, and I need to get it done in the next hour or two21:23
james_wI can merge then straight after though21:23
james_wwell, not *straight* after, I'd like some sleep :-)21:24
jelmerjames_w: No problem21:24
jelmerjames_w: Are you interested in conflict-free versions of these branches?21:24
james_wno, that's fine21:24
james_wit will be far more work for you to understand the new code than for me to make your changes to it21:24
james_wI would love it if you could test that branch for a few of your usual operations though.21:25
james_wthe 2.0 branch I mean21:25
jelmersure21:27
jelmerAny commands in particular?21:27
james_wbuilddeb has changed a couple of default locations21:27
james_wi.e. .. instead of ../tarballs and the results end up in .. as well21:27
james_wbut it should fall back for the first, and not break too much for the second21:28
james_wmerge-upstream and import-dsc have been completely re-written, so anything you can do with them would be great.21:28
jelmerbuilddeb itself is still doing the right things wrt paths21:29
james_wgood21:31
james_wthese changes set us up much better for the future.21:32
james_wsiretart: hi, sorry it's late, are you still around?21:32
jelmerjames_w, I can't find anything otherwise wrong doing some simple tests21:35
Odd_BlokeI want to push a bzr branch into an SVN repo using the space currently occupied by an empty directory.  Am I best off removing that directory and pushing the branch in, or is there some way I can avoid that?21:36
james_wjelmer: good to know, thanks. The test coverage has dropped a bit recently, so there could have been holes.21:36
jelmerOdd_Bloke, yes, you'll have to remove that directory and push using svn-push21:36
Odd_Blokejelmer: Thanks. :)21:37
loxsfolks, is there a way to make bzr write some "standard stuff" in the beginning of all of my files?21:45
LarstiQloxs: keyword expansion I suppose?21:46
loxsLarstiQ, i have no idea what is this, where is it in the docs?21:47
loxsi found it, thank you21:48
jelmerjames_w, one comment21:48
jelmerjames_w, any chance target_distribution and version can be options rather than arguments to merge-upstream?21:49
james_wwhy's that?21:49
jelmerjames_w, That makes it a lot easier to make either optional21:49
james_wah, for the later work?21:49
jelmeryeah, if it ends up in a release now it's going to hurt more people if it's changed later21:49
james_wyeah21:50
james_wthey are at the end, so you can drop them off without breaking things21:50
james_wthough they are probably the wrong way round for that21:50
james_wdoing it now21:51
jelmerjames_w, yeah, though I can also imagine target_distribution being optional (perhaps default to the distro the user is running?)21:51
james_wperhaps21:52
ronnyhow can i pull a single revision from one branch into another for merging?22:07
Odd_Blokeronny: 'bzr merge -c <revspec> <source>'22:07
acemowhen using bzr in command line on mac am getting this error for every command i type in.. "bzr: warning: unknown encoding . Continuing with ascii encoding." is there anything i can do to fix this?22:14
LarstiQacemo: is LANG/LC_CTYPE one of such set to something the system doesn't have?22:14
LarstiQacemo: see `locale` output22:14
acemoits UTF-822:15
LarstiQacemo: that should be fine22:17
* LarstiQ falls asleep22:17
LarstiQacemo: you could look at ~/.bzr.log22:17
ronnyhmm, why cant i just pull revs from other branches into a branch ?22:18
acemoLarstiQ: http://rafb.net/p/gWsCmO64.html heres my ~/.bzr.log22:19
jdobrienLarstiQ: re: bug #31059 it will be a while before i can get back to it22:27
ubottuLaunchpad bug 31059 in malone "Empty comments and empty emails generated" [Medium,Confirmed] https://launchpad.net/bugs/3105922:27
jdobrienLarstiQ: er bug #3015922:27
ubottuLaunchpad bug 30159 in bzr "paths are always from root of branch" [Low,Confirmed] https://launchpad.net/bugs/3015922:27
ronnywhats the name of the extension for graphical logs?22:30
awilkinsronny: Because Bazaar uses a Directed Acyclic Graph model ; to pull revs from other branches, you have to have the same ancestry. You can merge revs (if you don't have their ancestors, it's cherry picking though)22:30
awilkinsronny: qbzr and bzr-gtk both provide graphic logs22:31
awilkinsronny: qbzr has the superior log view in most people opinions22:31
ronnyawilkins: in my case they have the same ancestery, but bzr just errors telling me to use merge instead22:32
awilkinsronny: Have you committed revisions that the merge source does not have?22:33
ronnyyeah22:33
awilkinsronny: If you don't want to merge, rebase is your option (but I've yet to see a genuine reason to use it)22:34
ronnyi dotn see what should prevent a pull tho, it would just add a new head22:34
awilkinsRebase would be what you are aiming at ;; "just insert the revisions from the other branch before my new ones"22:35
awilkinsNot a good idea if you've pushed it elsewhere though22:35
ronnybut i just want to do get the revs into my branch, ONLY that22:35
awilkinsronny: You want to get rid of your new revisions?22:35
ronnyno22:35
awilkinsThen you merge, or you rebase22:36
awilkinsMerge does only merge the revisions you need22:36
awilkinsronny: Are you an existing SVN user?22:36
ronnyno22:36
ronnymonotone, git, mercurial22:36
acemois bzr 1.6 on mac still having the problems with utf-8?22:36
ronnythey all allow me to do what the heck i want, bzr is the only one getting into my way22:37
jelmerjames_w, --snapshot went away?22:38
james_wjelmer: yeah22:39
james_wit was completely broken by snapshot.debian.net dying22:39
james_wand I hadn't ported it to the new code, and it didn't seem worth it when there was nothing to get the packages from22:39
james_wit will come back when there is a new service22:39
jelmerah, ok22:40
jelmerpity, I didn't know snapshot.debian.net had died22:40
jelmerI never used --snapshot, just noticed that the arguments list had gotten shorter :-)22:40
james_wyeah, apparently they ran out of diskspace22:40
james_wit's going to become an official debian service22:40
james_wand hopefully that will still have all the history22:41
fullermdronny: Er, AFAIK, both git and hg will have the same behavior as bzr (though commands may be named differently).22:45
fullermdronny: mtn is the only one of the four that allows branches to have multiple heads.22:46
fullermd(well, there's that half-multi-head, half-named-branch, half-whatever thing that hg half does, but I don't know much about it)22:46
ronnyfullermd: hg allows me to have as many heads as i wanat in the same branch, git just needs different refs to them, but in general they wont force a merge on pull ever22:47
fullermdYes, but if they're different refs, they're not in the branch.  They're different branches (or pseudo-branches)22:47
ronnyin hg its valid in the same branch22:48
jamfullermd, ronny: I think the confusion is that hg/git use "pull" to just mean "fetch" but have no statement about actually doing anything with the revisions22:48
jamwhich causes multi-heads in hg22:48
jamand another branch pointer in git22:48
jamin bzr terms22:48
jamit would be "bzr branch other" into a shared repository22:48
jamto get the same behavior22:48
ronnyfor me thats just an unacceptable workflow enforcement22:49
clemente 22:58
clemente 22:58
clemente 22:58
clemente 22:58
clemente 22:58
lifelessclemente: I see blank lines22:58
clementelifeless: sorry, problems with my client. Hopefully I didn't send hundreds of lines a moment ago22:59
lifelessonly 5 :)22:59
clementeOk, so if you paste hundreds of lines, apparently you get kicked by the server :-)23:01
awilkins -!- clemente [n=Daniel@89.6.42.98] has quit [Excess Flood]23:01
clementeI won't do it again23:02
ronnyis there any way to go to a previous version?23:03
uwsronny: Read  "bzr help revert"23:04
ronnyuws: that doesnt exactly look like "go back to rev x"23:05
awilkinsYour question is vague23:06
lifelessronny: do you want your tree reverted to x, or your branch ?23:06
ronnythe tree23:06
uwsbzr revert -r12323:06
lifelessthen revert is what you want; it changes the tree and leaves the branch untouched23:06
uwsThat does EXACTLY look like "go back to rev x"23:06
lifelessronny: give it a go, tell us if its what you're looking for23:11
lifelessronny: then, if it is, I'd like to understand why you felt it wouldn't be23:11
ronnyworks23:12
lifeless(and if it isn't, well, we can talk about what you really want)23:12
[cliff]hi all23:12
[cliff]is there any progress on nested tree support?23:13
lifelessnot that I know of23:13
awilkinsShort answer ; no23:13
ronnylifeless: looks weird, first if all i expect a revert only to change my workdir (not alter its parents or anything else)23:14
awilkinsronny: The command is global to your tree by default ; try bzr revert . -r X instead23:14
ronnysecond i skiped to the long text, it just talks about reseting files to the orginal stuff, and how to get rid of stuff using merge23:14
lifelessronny: well, it hasn't changed parents23:15
[cliff]one more question: what is configmanager? how does it work? the page is kind of vague: http://bazaar-vcs.org/ConfigManager23:15
awilkinslifeless: I think he means `pwd` not `branch tree`23:15
ronnyoh, it really didnt23:15
ronnysorry there23:15
lifeless[cliff]: its a script I wrote quite some time ago ;) - it takes a list of relative-path:branchurl mappings, and then branches then for you, or updates them23:16
ronnyso there is bascially nothing like the stuff for git/hg/monotone that allow to go back to a previous rev and commit based on it other than a new branch ?23:16
lifelessronny: oh, so you *do* want to change the branch :)23:17
ronnyok, dammit, yet another set of terms23:17
awilkinsgit/hg/monotone are making a new branch, they are just doing it implicitly and are able to because they either store branches in a DB or in their repository folder23:17
lifelessronny: there shouldn't be any new terms here. But for clarity, let me lay them out:23:17
[cliff]lifeless, hmmmm I'm checking the sample config, looks useful for deployments. can I tell it to grab a specific revision/tag?23:17
lifelessrepository - could of history data23:18
lifeless[cliff]: it needs some love for its bzr support, 'probably' is the best answer offhand23:18
lifelessrepository - cloud of history data (same meaning as git/hg/monotone/svn/cvs/etc)23:18
lifelessbranch - a specific line of development in that cloud. its tip *may* be a head, or not. Same meaning as CVS/svn/git; same as hg named branches, not the same as monotone which is different to everything else23:19
lifelessronny: anyhow, 'commit' adds a new revision onto a branch, updating its tip in the process23:20
ronnyhg named branches may have more than one head23:20
lifelessronny: can they? I misunderstood them then. garh, I'll go read the code later23:20
lifelessanyhow, bzr branches are an explicit pointer to a revision id23:20
lifelessto commit on a different revision than the branches tip, *either* change the tip first, *or* make a new branch with a different tip23:21
lifelessto do the former : 'uncommit -r X' or 'pull --overwrite . -r X' will do what you want23:21
lifelessto do the latter, 'bzr branch -r X . ../newbranch'23:22
ronnyso i either kill later revs, or i need a new directory ?23:22
uwsbe careful since "uncommit" may make you lose code23:22
uws(and history)23:22
awilkinsronny: You could put your branch in a repo and use switching23:23
jamuws: no more than pull --overwrite23:23
jamuws: and with latest bzr, 'uncommit' will tell you how to get your pointer back23:23
lifelessuws: uncommit doesn't do an automatic gc23:23
awilkinsYou still have to make new directories for branches, but you can keep one working folder23:23
uwsjam: well, pull implies there's some history elsewhere :)23:23
uwsjam, lifeless: ah ok. didn't about recent developments23:23
jamuws: "bzr pull .- rXXX"23:23
ronnyoh pain :(23:23
lifelessronny: uhm23:24
uwsjam: (oops, missed the . )23:24
lifelessronny: I suspect we're seeing the tip of your needs23:24
ronnythat basically killing most of my workflows23:24
lifelessronny: perhaps you could give us a quick brushstroke picture, and we can then point you at either a guide, or give you a quick sketch now23:24
lifelessbecause I suspect we support your work flow just fine, but its spelt a little differently than you may be used to23:25
* awilkins suspects it's similar to this : http://www.g2one.com/quickcasts/movies/gitGrailsScreencast_web_final_compressed.mov23:25
lifelessawilkins: its similar to a proprietary format video?23:26
fullermdEasy creation of multiple branches/heads on the fly is handy if you're doing a lot of DAGgy-fixes'ing.23:26
awilkinsTHe video is one of some guy using git to rapidly switch between branches23:26
lifelessso shared repo & switch, or loom23:26
awilkinsSomeone posted it in here and I said the same thing23:27
ronnyi dont just switch betwen branches rapidly, but also betwen different parts of the history23:27
awilkins(apart from looms)23:27
lifelessronny: go on23:27
ronnyi usualy pull from a few people at once, then just jump betwen the various revs and take a look on what to merge23:28
lifelessso, I need to translate this into raw mechanics I think23:29
lifelessyou create a bunch of unmerged tips in your history store23:29
lifelessand then examine each one to see if you want to merge it23:29
lifelessand finally merge some onto your actual current branch tip ?23:29
ronnyyeah23:29
lifelessok23:30
lifelessI can tell you how I'd do this, which isn't the only way23:30
lifelesslet me just pastebin a small scenario23:30
lifelessronny: http://pastebin.com/d53f46e823:34
lifelessronny: this will be network and local space efficient23:34
ronnyany way to turn a normal repo to something like that?23:35
lifelessthe easiest way is just to branch your current tree into a shared repo23:36
lifelessbut if its GB's in size and you need to avoid having two copies temporarily, I can tell you how to flick bits to do it by hand23:36
ronnynothing big here23:39
ronnyguess i could just use that23:40
ronnystill puts having tonns of dirs on me23:40
fullermdCan't reconfigure do that?23:40
lifelessfullermd: probably, I haven't internalised it enough23:40
lifelessronny: each branch dir is tiny23:40
fullermdIt's got a --use-shared and --standalone.23:40
lifelessronny: it doesn't have a checkout of your code; so its only got a pointer, and configuration data23:40
ronnylifeless: i know they are tiny23:41
lifelessronny: ok :)23:41
lifelessronny: uhm, is there some scaling issue with directories for you? Or its a taste thing?23:41
uwsthe fact that branches ARE directory helps visibility23:42
ronnyits still extra management (i hate having dozens of dirs) and selecting special versions (that arent any tip) is still odd23:42
uwsthat helps a lot of users23:42
lifelessronny: ok, well, it sounds like dirs are more in your face than just names in a file?23:43
ronnyyeah23:45
ronnyall the branches and revisions are completely irelevant to me, till i actually want to take a look/merge23:46
ronnyhmm, does bzr 1.5 choke on tailing whitespace conflicts ?23:48
ronny(appearantly someone left them, and someone else has an autofix for those in the editor)23:49
lifelessoh23:50
lifelessI don't think we have a special-case flag for whitespace23:50
lifelessbut if its a clean 3-way it wont' conflict anyhow23:50
lifelessor you could use --lca which will likely do a better job23:51
ronnyhmk23:52
ronnyat least im done with that merge now23:53
=== mario_ is now known as pygi
ftais there a way to improve usability of bzr between 2+ computers ? i mean, a user is working in a branch on computer A, then move (or commute) and wants to continue on computer B, but the last changes are not committed (not ready)23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!