[00:00] <jam> just to mention, it seems to say that it needs "libsvn" but that isn't going to be installed
[00:00] <jam> So perhaps it doesn't install dependencies of Build-Deps ?
[00:00] <jam> So you have to explicitly enumerate all of them?
[00:00] <james_w> ah lpia
[00:01] <jam> I don't quite understand why it wouldn't complain on ~hardy, but maybe the packages already exist there?
[00:01] <james_w> subversion hasn't built on lpia in Intrepid
[00:01] <jam> james_w: well, it also failed for amd64
[00:01] <james_w> so it can't install the packages
[00:01] <james_w> with the same error?
[00:01] <jam> but it could be the same reason
[00:01] <jam> james_w: essentially
[00:01] <jam> http://launchpadlibrarian.net/17103816/buildlog_ubuntu-intrepid-amd64.bzr-svn_0.4.11-1%7Ebazaar1%7Eintrepid_FAILEDTOBUILD.txt.gz
[00:01] <james_w> the packages are there for amd64, so it shouldn't be the same
[00:03] <jam> james_w: well, it did fail, but I see what you mean from "rmadison" the packages *are* available for amd64
[00:03] <james_w> strange it has built on lpia, but rmadison doesn't list them
[00:03] <james_w> and it built ages ago, so it shouldn't be archive skwq
[00:03] <james_w> skew even
[00:05] <jam> I prefer skwq
[00:05] <jam> I think that is the root cause
[00:05] <jonnyde1> vreixo: regarding signing commits -- you can find information here: http://bazaar-vcs.org/ConfiguringBzr
[00:06] <james_w> heh :-)
[00:06] <LaserJock> does anybody know of any docs on how one might use looms with packaging?
[00:06] <james_w> LaserJock: I don't think there are any yet
[00:06] <vreixo> jonnyde1: The main doubt I have is how to choose the key used to sign
[00:06] <james_w> LaserJock: the NoMoreSourcePackages page gives an idea
[00:07] <jonnyde1> it is chosen by your configured bazaar identity
[00:07] <vreixo> sure? and it takes the email into account?
[00:07] <jonnyde1> it must be exactly the same as used in your key
[00:07] <jonnyde1> yes, AFAIK
[00:08] <vreixo> I've tried bzr sign-my-revisions and it uses a different key
[00:08] <vreixo> my identity is bzr whoami, no?
[00:08] <jonnyde1> yes, it is
[00:08] <james_w> it uses your default key I thought
[00:08] <james_w> I think there was a bug opened on this the other day
[00:09] <LaserJock> james_w: hmm yes, that does have some ideas on workflow. It seems a bit complicated though
[00:09] <jonnyde1> maybe it's the default key... but I think I've read somewhere that you should have the right whoami
[00:09] <jonnyde1> in fact, I'm doing it like this and it works....
[00:10] <jonnyde1> but try to set it as the default key in your keystore
[00:11] <vreixo> ok
[00:12] <james_w> LaserJock: complicated where? perhaps we can do better?
[00:12] <james_w> or just overall?
[00:13] <jonnyde1> vreixo: make sure you've set the whoami identity like: "Your Name<EMAIL_ADDRESS>[00:13] <vreixo> jonnyde1: I have
[00:13] <vreixo> I had
[00:14] <jonnyde1> ok
[00:14] <vreixo> jonnyde1:  $ gpg --list-keys
[00:14] <vreixo> pub   1024D/1635CB33 2008-02-20
[00:14] <vreixo> uid                  Vreixo Formoso<EMAIL_ADDRESS>[00:14] <vreixo> ...
[00:14] <vreixo> pub   1024D/66A4028A 2008-08-16
[00:14] <vreixo> uid                  Vreixo Formoso<EMAIL_ADDRESS>[00:14] <LaserJock> james_w: maybe complicated isn't quite the right word
[00:15] <vreixo> $ bzr whoami
[00:15] <vreixo> Vreixo Formoso<EMAIL_ADDRESS>[00:15] <vreixo> but it uses the other key!
[00:15] <LaserJock> james_w: maybe it's not very "packaging-like" but more "vcs-like"
[00:15] <jonnyde1> so maybe it's indeed an issue with the default key....
[00:17] <james_w> LaserJock: 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:18] <LaserJock> james_w: I don't think that's on NoMoreSourcePackage, but that might help
[00:19] <jonnyde1> vreixo: in your ~/.bazaar/bazaar.conf you should find your identity set by whoami, I think...
[00:19] <james_w> LaserJock: ah in the HCT stuff, so it's not quite the same thing
[00:19] <vreixo>  jonnyde1: it is right
[00:20] <james_w> LaserJock: 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_w> LaserJock: or, that's my hope anyway :-)
[00:20] <LaserJock> mhm, makes sense
[00:21] <james_w> so loom does this quite well I think
[00:21] <jonnyde1> vreixo: sorry, but that's the only advice I can give you... for me it worked right from the start...
[00:21] <james_w> perhaps topgit is better, but I think it's too complicated, and the task-oriented stuff will be harder
[00:22] <vreixo> jonnyde1: tanks anyway, I will try with the deafult key idea
[00:22] <LaserJock> james_w: do you know of any efforts for sort of an inbetween flow, between no VCS and NoMoreSourcePackages?
[00:22] <LaserJock> james_w: it seems like such a huge jump
[00:22] <jonnyde1> good luck! :)
[00:23] <james_w> LaserJock: 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 worth
[00:24] <james_w> LaserJock: 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 thing
[00:24] <LaserJock> james_w: right, at some point we just replace, debuild -S && dput *_source.changes, with bzr push
[00:24] <james_w> LaserJock: 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:25] <james_w> LaserJock: I hope so
[00:26] <LaserJock> james_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 twice
[00:27] <LaserJock> so I wonder what advantage all this workflow/vcs work is to them
[00:28] <james_w> I'm not sure
[00:28] <LaserJock> in essence, many developer may not care at all about history, feature branches, tracking patches, etc.
[00:28] <james_w> but if it makes their work easier and more efficient they will "care"
[00:28] <LaserJock> which makes NoSourcePackages possibly turn into a burden
[00:29] <LaserJock> well, that's the part that I'm trying to get my head around
[00:29] <LaserJock> how would it make their work easier and more efficient?
[00:29] <james_w> so an example from an hour or so ago
[00:30] <james_w> I had a sponsorship request open on lvm2 for a while, and in the meantime there were uploads to Ubuntu
[00:30] <james_w> I 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:31] <james_w> I ran bzr merge, and got everything merged, with a couple of merge conflicts
[00:31] <james_w> then committed and regenerated the request
[00:32] <LaserJock> ok, so in that the advantage was bzr's merging abilities
[00:32] <james_w> so, 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:33] <james_w> if 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 changelogs
[00:33] <james_w> *I* think that is so much easier
[00:34] <james_w> I know that I'm very comfortable with bzr though
[00:34] <LaserJock> it is, although i'm not sure how often we get conflicts
[00:34] <LaserJock> most of the time it's just download new package, re-apply patch, re-debdiff
[00:35] <james_w> but when it's not it's much harder
[00:35] <LaserJock> for sure
[00:35] <james_w> we have e.g MoM to automate this for merges
[00:36] <LaserJock> hmm, MoM-as-bzr would be interesting
[00:36] <james_w> we 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 anything
[00:36] <LaserJock> if we could just grab current Debian version, branch from MoM and work on the merge all in a bzr repo that'd be pretty sweet
[00:36] <james_w> and gives the same benefits whether we are in the easy case or the hard case
[00:36] <lifeless> jam: did you want a standup?
[00:37] <james_w> in phase 2 we will have Debian in bzr, so it would be simply "bzr merge lp:debian/unstable/gcc" or something
[00:37] <james_w> and MoM can do dry runs and publish results in the same way as now
[00:39] <LaserJock> james_w: sound quite interesting
[00:39] <LaserJock> can bzr make "quiltable" patch series? not sure if my terminology is quite right there, I don't use quilt
[00:39] <james_w> we need to do better at explaining these benefits, as I don't think many people see where we can go with this
[00:40] <james_w> yeah, it could, there's a couple of ways
[00:40] <james_w> it may be a good way to go.
[00:40] <LaserJock> I wonder how good collaboration with Debian would go
[00:40] <james_w> one problem at the moment that merging debian/patches/* really screws you up, we need to improve that somehow.
[00:40] <james_w> so converting to bzr on the way in, and then converting back when building the source package would be one way
[00:41] <LaserJock> I'm kinda getting to the point where perhaps just sharing patches rather than debdiffs or DVCSs is the way to go
[00:42] <james_w> so 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 that
[00:42] <james_w> thought generating plain patches is good for 90% of cases or more
[00:43] <LaserJock> hmm, yeah
[00:44] <LaserJock> if 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 cool
[00:45] <lifeless> if you use looms to manage the Ubuntu branch, thats totally doable
[00:45] <lifeless> probably 20 lines of python to add a command to do that to loom
[00:45] <LaserJock> rockin'
[00:46] <lifeless> james_w: so the gtk one, what do you need from me? I can't upload to main..
[00:47] <james_w> is -gtk main?
[00:47] <james_w> nope, universe
[00:47] <lifeless> oh huh universe
[00:47] <lifeless> can't you upload it then ? :)
[00:47] <james_w> nope
[00:47] <lifeless> hmm, syncs are meant to be done by archive anyhow
[00:48] <james_w> lifeless: yeah, but I needed a sponsor to ACK it for the archive admins to look at it
[00:48] <james_w> well, confirm it and subscribe ubuntu-archive
[00:48] <lifeless> I've commented on both
[00:48] <lifeless> hmm, am I still in sponsors
[00:49] <james_w> you don't need to be in the team as far as I know
[00:49] <LaserJock> I'm in ubuntu-{universe,main}-sponsors if you need anything
[00:49] <james_w> thanks LaserJock
[00:49] <lifeless> LaserJock: if you could process https://bugs.edge.launchpad.net/ubuntu/+source/bzr-svn/+bug/261653
[00:49] <lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/bzr-gtk/+bug/261645
[00:49] <james_w> LaserJock: would you be willing to ack a couple of main sync requests as well then please?
[00:49] <lifeless> I don't do enough syncs to keep it all paged in, I was just checking the current procecss
[00:50] <lifeless> james_w: where is the bzr 1.6 sync request?
[00:50] <LaserJock> james_w: depends on how many ;-)
[00:50] <james_w> lifeless: bug 261636
[00:50] <lifeless> LaserJock: 3
[00:50] <lifeless> LaserJock: I think thats all
[00:50] <james_w> LaserJock: that one, and bug 261644 to go with it
[00:51] <lifeless> 4
[00:51] <lifeless> :P
[00:51] <james_w> then bzr-svn sync for universe, and bzr-gtk merge
[00:51] <LaserJock> ok, so bzr-* ? :-)
[00:52] <james_w> jelmer has already done all the lesser plugins and got acks, so with these four we get most-recent everything, with everything compatible
[00:52] <lifeless> jam: ping
[00:52] <jelmer> lifeless, if you feel like uploading bzr-search, maybe that can make it into intrepid as well
[00:52] <jelmer> almost made it earlier but got rejected because of incorrect debian/copyright
[00:53] <lifeless> jelmer: garh
[00:53] <lifeless> jelmer: url me up I guess
[00:53] <lifeless> packaging is so 1960's though
[00:54] <jelmer> lifeless, http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=bzr-search
[00:54] <jelmer> lifeless, are you calling me oldfashioned?  IDIOTS
[00:56] <jelmer> yeah, sorry, I gave the link inside the login area
[00:56] <lifeless> hmmm, I'm not in the most forgiving-of-the-universe modd today
[00:56] <jelmer> lifeless, http://mentors.debian.net/debian/pool/main/b/bzr-search/ should work better
[00:56] <lifeless> oh yay
[00:56] <jelmer> now what ? :_)
[00:56] <lifeless> stupid robots.txt defeats wget
[00:57] <lifeless> manually copying urls now
[00:57] <lifeless> *this* is why I don't sponsor much
[00:57] <lifeless> its about 4 billion times harder than it should be
[00:57] <jelmer> well, at least you *can* sponsor
[00:57]  * jelmer just lost another application manager
[00:58] <lifeless> !
[00:58] <lifeless> are you a MOTU yet?
[00:58] <jelmer> no - I don't do much Ubuntu stuff, I always work in Debian and then request syncs
[00:58] <lifeless> jelmer: because its so much easier, apparently ? :)
[00:59] <jelmer> it is, once the initial package is in. I probably wouldn't be using or developing for Debian if that hadn't made it
[00:59] <LaserJock> if you've got packages that can be just synced it's nice to just maintain in Debian
[01:01] <lifeless> jelmer: there will be a delay
[01:02] <lifeless> I need to update my sid
[01:02] <lifeless> oh
[01:02] <lifeless> crud, other machine
[01:02] <lifeless> ETOOHARD
[01:03] <lifeless> the packaging looks ok, though the reference export command is stale
[01:04] <LaserJock> bzr done
[01:05] <jelmer> lifeless: It's mainly there to make ftp-master happy, I'll add a get-orig-source target later
[01:05] <lifeless> jelmer: also it looks like you've got a bzr 1.5 deps, but it requires 1.6
[01:05] <lifeless> Build-Depends-Indep: bzr (>= 1.5~)
[01:05] <jelmer> lifeless, it only build-depends on 1.5, the actual dependency is on 1.6
[01:06] <jelmer> I'll fix the build-dep, it should be harmless though
[01:06] <lifeless> That needs a comment if its deliberate, or not to be different
[01:06] <lifeless> well, the sid chroot is updating
[01:06] <jelmer> lifeless: Yeah, I'm fixing it here; it's cosmetic though
[01:06] <lifeless> be quite a while
[01:08] <jelmer> lifeless, thanks for looking into this
[01:11] <lifeless> jelmer: I'm about given up on it; another headache and it will be ETOOHARD - too much to do
[01:15] <jelmer> lifeless: :-(
[01:16] <lifeless> there is _so_ much beauracracy involved its insane
[01:16] <lifeless> you'll still have to wait for NEW
[01:17] <jelmer> please don't get me started
[01:17] <lifeless> we practice crunchy shell security as far as copyright honoring goes
[01:17] <jelmer> NEW's been pretty quick in the last few weeks
[01:17] <lifeless> it may catch a bunch of stuff; but as all debian/copyright does is duplicate whats in the package already, it doesn't help anything
[01:18] <jelmer> ...  and if a new upstream release adds weird stuff, there's no review at all from ftp-master
[01:18] <lifeless> thats what I mean by crunchy shell
[01:18] <jelmer> ah
[01:18] <lifeless> once you're in, you're in.
[01:18] <jelmer> When I think of shell, I think of "shell script"
[01:19] <lifeless> its a standard description of certain risk management techniques
[01:22] <jelmer> ah
[01:22] <jelmer> well, nothing's perfect, but it can indeed be pretty frustrating at times..
[01:23] <jelmer> lifeless, any luck getting it to build?
[01:24] <lifeless> chroot still updating
[01:35] <LaserJock> bzrtools done
[01:38] <LaserJock> bzr-svn done
[01:40] <lifeless> jelmer: sorry, I'm going to have to leave bzr-search
[01:41] <jelmer> lifeless, :-(
[01:42] <jelmer> beuno, ping
[01:42] <lifeless> the reason I do nearly everything I do do for ubuntu is source uploads
[01:42] <LaserJock> james_w: you need to remember to update the Maintainer field in debian/control :-)
[01:43] <lifeless> only takes a few minutes fighting pbuilder + debbuild & deps etc and my tolerance for incoherent toolchains is exceeded
[01:43] <james_w> LaserJock: damn, thanks for catching it.
[01:43] <james_w> LaserJock: I presume you don't need a new debdiff?
[01:43] <LaserJock> james_w: no, I just run update-maintainer
[01:44] <james_w> cool, thanks
[01:44] <LaserJock> however, it does dep on the newer bzr
[01:44] <LaserJock> so I'm not sure if I should upload until that's sync'd
[01:45] <LaserJock> I guess I could just let it fail and then somebody can hit the retry button :-)
[01:48] <jelmer> lifeless, I can provide you with a pre-built package... :-)
[01:48] <lifeless> jam1: are you back ?
[01:48] <lifeless> jelmer: I can't upload that
[01:48] <jelmer> siretart: Could you perhaps sponsor bzr-search?
[01:49] <jelmer> lifeless: Why not?
[01:49] <lifeless> jelmer: thou shalt not upload binaries thou didst not build thyself
[01:49] <james_w> LaserJock: it should just auto-depwait shouldn't it?
[01:50] <LaserJock> james_w: well, one would hope but I'm not 100% positive
[01:50] <james_w> or at least manual depwait
[01:50] <jelmer> lifeless: Why? Yes, I could've tampered with the binary but once the package is in sid, I can upload newer versions without intervention.
[01:51] <james_w> I'd suggest just getting it in, and then fixing if we need to, but you're the sponsor
[01:51] <lifeless> jelmer: its part of the stuff I agreed to when I became a DD
[01:51] <jelmer> lifeless: hmm, ok
[01:52] <LaserJock> james_w: uploaded
[01:52] <james_w> LaserJock: great, thanks a lot
[01:52] <LaserJock> james_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_w> true, I saw that afterwards
[01:53] <james_w> it's already committed upstream though, so it's not a long-term problem
[01:53] <LaserJock> but without a patches/ it's just an extra dep
[01:53] <james_w> yup
[01:54] <LaserJock> anywhere, there's a complete bzr set
[01:54] <LaserJock> which makes me happy, i got to do more than complain about things being out of sync :-)
[01:54] <james_w> perfect, that puts Intrepid in good shape
[02:00] <jelmer> well, the packaging spree was nice while it lasted
[02:01] <jelmer> uni starts again on friday, so I guess I'll changing the remaining ones back to RFPs for now
[02:01] <markh> I think I'm suffering branch overload.  One of my working trees is 4 branches away from its ultimate upstream...
[02:01] <lifeless> markh: you might like looms
[02:01] <lifeless> jelmer: how far did bzr-git get?
[02:02] <markh> I'm not sure I need *more* bzr workflow options at this point... ;)
[02:02] <jelmer> lifeless: I ended up working mostly on fixing bugs in bzr-svn
[02:02] <markh> I only just use shelve for the first time the other day - wonderful :)
[02:02] <jelmer> lifeless: bzr-git can now do clone/pull from git -> bzr
[02:02] <lifeless> cool
[02:03] <lifeless> does git keep a hot refcount for each hash?
[02:03] <lifeless> or is gc a global operation ?
[02:03] <jelmer> lifeless: also, tags can be set, info works and log works again
[02:03] <jelmer> afaik its global but I'd have to check to be sure
[02:04] <james_w> you mean does it walk the heads to find unreferenced objects?
[02:09] <lifeless> james_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 0
[02:09] <lifeless> james_w: doing race free with loose objects will be quite a challenge though
[02:09] <james_w> ah, I see
[02:10] <james_w> I think
[02:10] <james_w> I don't know how it does that
[02:39] <jdong> May I make the suggestion for more user-friendly release notes?
[02:39] <jdong> I think users are interested in something more readable than the release notes format, which seems to appeal to developers of bzr more.
[02:40] <jdong> I'm thinking something in the form of Ubuntu's tours would cater better to end users (highlighting major improvements, new features, etc)
[02:41] <lifeless> would you like to help write something like that? That would be really nice
[02:42] <jdong> I'd certainly be glad to contribute to such an effort
[02:43] <lifeless> I think we'd be happy to have release notes in such a form, as long as its contributed :)
[02:44] <jdong> :)
[03:12] <lifeless> jam1: ping
[03:48] <abentley> jelmer: Why did handle-patch stop being a command?
[03:48] <abentley> jelmer: And have you noticed it's full of tabs?
[04:00] <frikazoyd> Howdy
[04:03] <frikazoyd> Anyone around who can answer a quick question?
[04:06] <bob2> go for it
[04:06] <frikazoyd> Cool
[04:06] <frikazoyd> So, I discovered Bazaar through a friend, and was thinking about moving my development/playtesting team to it.
[04:06] <frikazoyd> (Mod team)
[04:07] <frikazoyd> I tried installing 1.6, and everything I can find says TortoiseBZR comes with the windows install.
[04:07] <frikazoyd> However, I don't see the TortoiseBZR shell integration, even after a reboot.
[04:07] <frikazoyd> Is there anything special I have to do to get it working?
[04:09] <frikazoyd> Ahhh, 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] <frikazoyd> Takes asking it before you figure it out I guess, heheh.
[04:12] <bob2> http://bazaar-vcs.org/WindowsDownloads doesn't seem to mention tortoisebzr, though
[04:13] <lifeless> markh: what's needed for win64?
[04:13] <markh> py2.6 on windows
[04:13] <markh> apart from that, not much ;)
[04:13] <markh> bashing the required extension modules into shape
[04:13] <lifeless> is py 2.6 not on windows yet ?
[04:13] <markh> pywin32 is already there
[04:14] <markh> earlier py versions use MS compilers with sucky/no support for 64bits
[04:14] <markh> py2.6 is using the latest MSVC and makes life easy
[04:14] <markh> py2.5 on windows is at the same place on windows as any other os roughly...
[04:15] <markh> 2.6
[04:15] <markh> stable in my experience
[04:16] <markh> FWIW, a 64bit native exectable can often see 15%ish perf improvement over running a 32bit version of the exe on the 64bit os.
[04:17] <markh> frikazoyd: ah, sorry, I didn't see your comments.  Yes, 64bit toirtoise will need to wait a little while
[04:18] <markh> there is a hacky work-around
[04:18] <frikazoyd> Ok
[04:18] <frikazoyd> Well I don't mind running the 32 bit
[04:18] <frikazoyd> to be honest
[04:18] <frikazoyd> but the 32 bit installer didn't install tortoise bzr
[04:18] <markh> IIRC, executing "\windows\syswow64\explorer.exe /separate" should start a new 32bit version of explorer that works with toirtoise
[04:18] <frikazoyd> for some reason
[04:18] <frikazoyd> or it just isn't showing up
[04:18] <markh> didn't install, or didn't register?
[04:18] <frikazoyd> Ah, ok
[04:18] <markh> right - it registered as a 32bit extension
[04:19] <frikazoyd> Well it said it registered tortoise in the installer
[04:19] <frikazoyd> AAAhhhhhh
[04:19] <markh> only 32bit executables will see it
[04:19] <lifeless> gotta love that old MS style
[04:19] <frikazoyd> and my explorer is 32 bit
[04:20] <markh> hrmph
[04:20] <lifeless> thunk layers? We're tired of that, WoW blew chunks, lets not do that again
[04:20] <frikazoyd> Yeah, I'm not a fan.  However, my hands are tied since I'm a Source modder
[04:20] <lifeless> frikazoyd: oh cool.
[04:20] <markh> windows supports 32bit processes via a "wow" (windows on windows) layer, which is basically a thunking playground.  It *does* support loading 32bit binaries into 64bit executables
[04:20] <markh> which is what COM and shell extensions are all about
[04:21] <frikazoyd> Hm
[04:21] <markh> bugger
[04:21] <lifeless> markh: yes, YHBTHANDHTH
[04:21] <markh> s/*does*/*does not*/
[04:21] <frikazoyd> Hrm, the workaround didn't let me see the shell extension
[04:21] <frikazoyd> ah well, I don't mind using command line
[04:21] <lifeless> markh: the 16-32 bit wow did allow OLE to work across boundaries IIRC
[04:21] <frikazoyd> the 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] <lifeless> markh: which is what my mini-troll was about
[04:22] <markh> lifeless: yess, out-of-process COM can be marshalled
[04:22] <markh> we are inproc
[04:22] <lifeless> markh: can't you just set an oop registration anyway?
[04:22] <lifeless> :)
[04:23] <markh> frikazoyd: 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++ anyway
[04:23] <frikazoyd> Okay
[04:23] <markh> lifeless: shell extensions only work in-proc unfortunately
[04:23] <frikazoyd> Well 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:24] <frikazoyd> Though I'm not bad with C++ itself
[04:24] <markh> a .msi would be good :)
[04:24] <markh> but we need to sort out other internal packaging issues before we take on a different installer
[04:24] <frikazoyd> ok
[04:24] <lifeless> man
[04:25] <lifeless> I so love how COM is inconsistent
[04:25] <lifeless> 'its totally generic' -> except that its not
[04:25] <markh> heh - for sure.  Plenty of scope for tuning etc.
[04:26] <markh> but the rate of calls made to shell extensions and the blobs passed around would make an out-of-proc system struggle
[04:26] <lifeless> markh: thats no reason not to -permit- it
[04:26] <lifeless> markh: (also, they could fix the interface to do less work more sanely)
[04:26] <markh> All the interfaces would need custom marshallers iiuc
[04:26] <markh> and there are *lots* of them
[04:27] <markh> all the interfaces are defined in terms of c++ structs, not nice little COM variants etc
[04:27] <markh> its really just using COM as a "plugin" mechanism in some ways :)
[04:27] <markh> I'm not defending things, just trying to add perspective ;)
[04:30] <lifeless> markh: remember, I'm an ex-cygwin-core dev :P
[04:30] <markh> lifeless: ahh, never knew that :)
[04:30] <lifeless> search for robert collins cygwin :)
[04:32]  * markh wonders what else has can come up with by putting various words after "robert collins"...
[04:32] <lifeless> beware my evil clones
[04:32] <lifeless> theres a rc writes for dr dobbs journal
[04:33] <lifeless> and another in a uk python-using research job
[04:33] <markh> oh - another as a porn star I see! ;)
[04:33] <lifeless> oh really? cool
[04:33] <lifeless> now I can get a real hackergotchi
[04:33] <lifeless> :P
[04:35] <fullermd> They're everywhere these days.  I think there's one stealing my name too.
[04:35] <em1> good morning
[04:37] <em1> cant donwload openerp's source by running 'python bzr_set.py',
[04:37] <em1> wait long time and no file is downloaded
[04:37] <em1> last time i can download all files
[04:38] <em1> but this time after installed symlink plugin, it become calm down very much
[04:39] <em1> seems that python run into a dead loop or no connection for ever
[04:39] <em1> it do create a directory, but no files
[04:39] <bob2> what is bzr_set.py?
[04:39] <em1> bob2, it is from lp:openerp
[04:40] <bob2> the 'openerp's default branch on launchpad doesn't contain openerp?
[04:41] <em1> do you means the trunk?
[04:41] <bob2> yes
[04:41] <em1> yes, it contains only two files
[04:41] <em1> one is bzr_set.py, other is a readme
[04:42] <bob2> bizarre
[04:42] <em1> readme file say need run bzr_set.py to fetch source
[04:42] <em1> bob2, what?
[04:46] <bob2> that's a bit baroque
[04:48] <em1> bob2, do you have advice to detect where it go wrong?
[04:48] <bob2> well, it will take a while
[04:48] <bob2> you could just try checking out the code manually
[04:49] <em1> how to do manually?
[04:49] <bob2> look in the file, bzr_repository lists the urls it is fetching
[04:49] <bob2> just "bzr branch" them
[04:53] <em1> .bzr\repos...\upload have a big file sized of 27M, is it ok?
[04:56] <jam> lifeless: pong
[05:00] <lifeless> jam: hey
[05:00] <lifeless> jam: trade you a review of log [rather than a comment] for a review of btree ? :)
[05:01] <jam> sure
[05:06] <em1> i report a bug justnow, dont know if it is a bug:  Bug 261733
[05:17] <jam> lifeless: btw, you asked for me to factor out the common code, but the loops really aren't the same.
[05:17] <jam> I'm I misunderstanding what you are asking me to refactor?
[05:19] <lifeless> oh
[05:19] <lifeless> the add_node method looked like a extract from the base class, verbatim
[05:20] <jam> lifeless: no, self._nodes contains different things in each
[05:20] <jam> BTree doesn't need to track absent nodes
[05:20] <lifeless> ok
[05:20] <lifeless> have a look, see if there is enough to do something common
[05:20] <lifeless> otherwise ok
[05:21] <jam> I could probably extract the "_check_node" into a helper
[05:31] <em1> until now, the source is downloaded but not over, why so slowly, my adsl bandwidth is 2mbps
[05:34] <lifeless> em1: what url is the source coming from?
[05:36] <em1> that is lp:openerp
[05:37] <bob2> http://bazaar.launchpad.net/%7Eopenerp/openerp/package-script/annotate/9?file_id=bzr_set.py-20080708192342-trihj558tjhh9549-2, line 22
[05:37] <bob2> (lp)
[05:39] <lifeless> have you logged into launchpad?
[05:39] <lifeless> in bzr
[05:42] <em1> me?
[05:42] <lifeless> yes
[05:43] <em1> no, i dont know how to log into lp
[05:43] <lifeless> ok, then it will be doing http requests
[05:43] <lifeless> it should stream fast
[05:44] <lifeless> if its not, its likely a ISP problem; e.g. a broken intercepting proxy
[05:44] <em1> i try bzr antherproj, it finished quickly
[05:45] <em1> all project do host on the same computer?
[05:45] <mwhudson> yes
[05:45] <em1> maybe because of openerp have very much codes to download
[05:46] <em1> for nearly 2 hours, it still not finish downloading
[05:46] <em1> not wonder there is a virus somewhere
[05:48] <jam> Well, http://bazaar.launchpad.net/~openerp/openerp/package-script/.bzr/repository/packs/
[05:48] <jam> is only a few K
[05:48] <jam> but that is just the packaging?
[05:49] <bob2> yeah, it then scripts branching 5 other ones
[06:03] <lifeless> jam: just sent you a toy
[06:32] <gour> didn't know that python is considering bzr..today on reddit http://pyside.blogspot.com/2008/08/quick-hgbzr-timings.html
[06:33] <gour> is this another 'apples & oranges' benchmark?
[06:35] <LaserJock> I wonder why 1.6 is often slower than 1.5
[06:35] <LaserJock> although the branch time looks like a big improvement
[06:38] <RAOF> jml: Oooh.  Is bzr upgrade over bzr+ssh substantially faster than sftp?
[06:38] <gour> clone time is showstopper, at least, it was for ghc evaluation
[06:39] <RAOF> Really?  It's essentially a one-off time, though.
[06:39] <jml> RAOF: I don't have any data on that. My guess is "yes".
[06:39] <jml> RAOF: because there should be fewer roundtrips and much less data being transferred.
[06:39] <lifeless> LaserJock: memory
[06:39] <lifeless> theres a peak memory use bug in 1.6
[06:40] <gour> RAOF: yeah, it is, but although having many advantages over candidates, it was ruled out due to speed - mostly based on 'clone'
[06:40] <lifeless> upgrade over either will be the same
[06:40] <jml> my understanding of clone time is that 'time to branch' and 'time to build working tree' should be measured separately.
[06:40] <RAOF> jml: Given bzr+ssh requires a server-side copy of bzr (IIUC), theoretical maximum performance would seem likely to be very fast.
[06:40] <jml> lifeless: it just uses vfs methods?
[06:40] <gour> jml: right
[06:41] <lifeless> yes
[07:01] <vila> jam: I'm already working on it, but thanks for the reminder
[08:02]  * jml types 'bzr record "hello robert"'
[08:08] <lifeless> hello jml
[08:08] <jml> :)
[08:09] <jamesh> apparently the command is useful for something
[08:11] <lifeless> jamesh: why 4 the troll?
[08:12] <jamesh> lifeless: 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 records
[08:13] <lifeless> jamesh: thats true
[08:13] <lifeless> jamesh: really need 'merge' implemented
[08:13] <jamesh> and I guess it'd be nice if it happened automatically at relevant points in time
[08:14] <lifeless> I'm less sure about that; 'bzr push' doesn't do an implicit commit
[08:14] <lifeless> I think it would weird people out majorly if it did :)
[08:14] <jamesh> perhaps committing to the top thread would be worth recording
[08:14] <lifeless> I'd like to have merge working robustly before looking at that sort of automation
[08:15] <jamesh> or recording every commit
[08:15] <jamesh> (that is slightly dubious, due to possible conflicts in higher threads)
[08:15] <lifeless> right
[08:15] <lifeless> or in lower threads for that matter
[08:20] <jamesh> so 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:27] <lifeless> jamesh: I agree with both
[08:27] <lifeless> but trolling doesn't get merge written
[08:27] <lifeless> there are benefits right now, in that is does allow revert-loom
[08:27] <lifeless> but its not a great benefit
[08:38] <jml> and 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:39] <jml> which basically means "before meals".
[08:41] <siretart> jelmer: bzr-search uploaded, but I wasn't able to commit my changes: http://paste.debian.net/15695/ - what's going on here?
[08:41] <techtonik> Does bzr support branching from subtrees of original repository or I always need to copy whole directory tree when branching?
[08:41] <lifeless> thumper: always full tree
[08:41] <siretart> jelmer: and I uploaded to experimental, since it seems to depend on bzr 1.6, which is not available in unstable
[08:41] <lifeless> techtonik: ^
[08:42] <thumper> lifeless: morning
[08:45] <techtonik> lifeless: 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_w> siretart: you would need a --rich-root-pack repo for the local checkout of bzr-search, as the alioth repo is in a rich-root format
[08:46] <james_w> siretart: would you be available for an upload of builddeb later today?
[08:46] <lifeless> techtonik: 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] <lifeless> techtonik: we have a planned feature to help, but its planned not implemented
[08:46] <lifeless> hi thumper
[08:49] <lifeless> ok, bzr-search rockage :)
[08:49] <lifeless> robertc@lifeless-64:~/source/baz/log$ time ./bzr log ../bzr.dev -m "robert" > /dev/null
[08:49] <lifeless> real    0m12.357s
[08:49] <lifeless> robertc@lifeless-64:~/source/baz/log$ time ./bzr log ../bzr.dev -m "\brobert\b" > /dev/null
[08:49] <lifeless> real    0m4.706s
[08:51] <siretart> james_w: sure
[08:51] <james_w> siretart: great, thanks
[08:51] <techtonik> lifeless: The current tree is about 900Mb (lp:codeblocks) - not much for an HDD, but too much for my internet limits.
[08:52] <lifeless> 900MB for the working tree? or the full history?
[08:53] <techtonik> Working tree only/
[08:53] <bob2> they eclipsed eclipse!
[08:53] <lifeless> jeepers
[08:53] <lifeless> thats...insane
[08:53] <techtonik> Actually 450 Mb as it is SVN checkout, but still too much.
[08:54] <bob2> how on earth is it all in one branch?
[08:54] <bob2> the full linux binaries are 20MB
[08:54] <siretart> james_w: just tell me what is the up-to-date branch I should upload. and do you want it for unstable or experimental?
[08:55] <techtonik> SVN import - that is.
[08:55] <james_w> siretart: experimental and intrepid, if you don't mind, to save a sync delay.
[08:55] <james_w> siretart: I don't have a branch yet though, I still have some work to do.
[08:56] <siretart> james_w: ah, okay.
[08:56] <techtonik> UFO:AI repository with media files takes even more than 1Gb
[08:58] <techtonik> I'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:59] <techtonik> Now I can't merge changes from the main trunk into my branch, because they do not have any common ancestors in bzr.
[09:05] <techtonik> When I supply some "-r BASE..LAST" revision argument to merge, then bzr comes up with a lot of conflicts. http://pastebin.com/m75a6caa6
[09:06] <techtonik> I wonder how can I resolve them? The ones about unversioned directories, for example.
[09:07] <bob2> well, you could start over and re-add everything with the same id's as are used in the trunk
[09:07] <bob2> but that's not a huge amount of use
[09:13] <techtonik> Does that mean I will lose all the history?
[09:14] <bob2> which history?
[09:14] <bob2> well, yes, either way
[09:36] <techtonik> Ok, 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:37] <lifeless> jelmer: done a 1.6 bzr search release
[09:55] <jelmer> abentley, was required to be able to register it as a mime type handler
[09:55] <jelmer> siretart, thanks!
[09:55] <jelmer> lifeless, ok
[10:09] <techtonik> So, Bazaar doesn't have partial checkouts? =/
[10:09] <lifeless> the answer hasn't changed from earlier :)
[10:10] <lifeless> its planned
[10:10] <lifeless> not implemented
[10:10] <awilkins> ls
[10:10] <awilkins> Oops
[10:10] <lifeless> ['.', '..']
[10:11] <awilkins> Is there a plugin that will snapshot a workspace of multiple trees so you can check out the same thing elsewhere?
[10:11] <lifeless> multiple trees?
[10:11] <awilkins> Multiple branches or checkouts
[10:11] <lifeless> like nested, or same project or ...?
[10:12] <awilkins> Say - an eclipse workspace containing multiple branches
[10:12] <awilkins> The workspace is not a branch, but the projects inside are
[10:13] <siretart> awilkins: check 'config-manager'
[10:13] <awilkins> I knew I'd seen something
[10:15] <awilkins> Isn't that your project, lifeless?
[10:18] <lifeless> yes
[10:18] <lifeless> but its about trees, not branches :P
[10:31] <lifeless> awilkins: probably needs some love to do what you want, but yeah config manager is what you'd want for N branches of the same project
[10:32] <awilkins> It's more 1 branches of N projects
[10:32] <lifeless> that sounds more like nested trees to me then
[10:32] <awilkins> Not in the same tree
[10:32] <lifeless> cm still applicable
[10:32] <awilkins> Siblings in a container
[10:33] <awilkins> Like an eclipse PSF file
[10:33] <awilkins> psf == cm recipe
[10:33] <awilkins> Is it just a straight file?
[10:34] <awilkins> Or is it versioned so you can do things like merge it from other workstations?
[10:34] <lifeless> cm doesn't care
[10:34] <lifeless> you can version if if you want :P
[10:34] <awilkins> Would it handle switches?
[10:35] <awilkins> e.g. you switch the branch on your workstation, you sync cm recipe on laptop, cm switches to same branch ?
[10:38] <lifeless> it has a switch command
[10:38] <lifeless> its not well maintained cause I've been putting it of for nested trees
[10:38] <awilkins> Fair enough
[10:38] <lifeless> but I may need to give it some love
[10:38] <lifeless> anyhow, yeah poke at it
[10:47] <Peng_> beuno: Shouldn't Loggerhead's /static/ URLs generate Expires headers and stuff?
[10:48] <beuno> Peng_, maybe. I don't know that much about http voodoo
[10:50] <lifeless> Peng_: they all should; mwhudson is working on it
[10:50] <Peng_> lifeless: Yeah, I just saw that bug. Maybe I should add a comment to remind him about the static stuff?
[10:51] <lifeless> sure
[11:03] <Peng_> Wow, changing that is actually a one-line patch.
[11:20] <Peng_> Is there any point to GPG-signing a very trivial email, with an untrusted key? :)
[11:37] <EarthLion> erm i have an issue where bzr doesn't seem to be recognising 2 new files that have been created
[11:38] <luks> which command specifically?
[11:38] <EarthLion> when i commit it says there are no changes
[11:38] <EarthLion> when there clearly are
[11:38] <luks> and diff shows changes?
[11:38] <luks> or status
[11:38] <EarthLion> diff shows no changes
[11:38] <luks> er, wait
[11:39] <beuno> maybe they're ignored?
[11:39] <luks> they are new files, did you add them?
[11:39] <luks> `bzr add`
[11:39] <EarthLion> nope they were created by a web application
[11:39] <luks> then you need to add them first
[11:39] <EarthLion> expression engine saves new templates as templates
[11:39] <luks> bzr add path/to/file
[11:40] <EarthLion> i thought it did that automatically though?
[11:40] <Peng_> It does not
[11:40] <luks> no, it doesn't
[11:40] <luks> bzr status should also tell you about unknown files in the working tree
[11:41] <EarthLion> thanks i can see the file now
[11:41] <EarthLion> can you set it up to automatically add new files?
[11:41] <luks> I think there was a patch to add an option to bzr commit to do that, but it was rejected
[11:42] <EarthLion> that seems v.odd that it isn't there
[11:42] <EarthLion> i presumed it did that automatically
[11:42] <EarthLion> in a project files are always being added...
[11:42] <luks> I don't know about others, but I usually have files in the working tree I don't want to version
[11:42] <EarthLion> so I have to manually add all new files?
[11:42] <luks> you can just run 'bzr add'
[11:43] <luks> it will add all unknown files
[11:43] <EarthLion> ah ok thanks luks
[11:43] <EarthLion> excellent thanks for the concise information :)
[11:45] <luks> http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/45138 is the ML thread, btw
[11:48] <EarthLion> thanks a lot :)
[12:29] <techtonik> If I can't make a partial ceckout, can I download a part of a tree without version history?
[12:30] <lifeless> I think my patch allowing 'export target branch/subdir' is in 1.6
[12:32] <techtonik> doesn't seem so
[12:33] <techtonik> bzr export xxx http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk
[12:33] <techtonik> bzr export xxx http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk/src
[12:33] <techtonik> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk/src/".
[12:33] <techtonik> Bazaar (bzr) 1.6
[12:44] <techtonik> lifeless: 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:45] <lifeless> techtonik: well, bzr.dev should do bzr export xxx http://bazaar.launchpad.net/~vcs-imports/codeblocks/trunk/src
[12:46] <lifeless> and there will a new loggerhead sometime soon that can export subdirs
[12:46] <luks> techtonik: is it really a problem to download ~60MB of data?
[12:55] <techtonik> luks: 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 modem
[12:55] <luks> ouch :(
[12:56] <luks> and I thought my connection was expensive
[13:06] <jam> vila: Just to make sure, Robert is discussing a "trie" not specifically a "tree". http://en.wikipedia.org/wiki/Trie
[13:06] <jam> I haven't gotten through all of your email yet, though.
[13:09] <vila> jam: 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 indirectly
[13:09] <vila> wtf ? plugin.gtk.test prompting me during selftest ???
[13:16] <vila>  (55, 'select/poll returned error') now, some have decided to die *today* :)
[13:16] <vila> s/some/some bugs/
[13:21] <lifeless> vila:  a trie is a radix tree
[13:21] <jam> vila: 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 tree
[13:21] <jam> So if you already have one built
[13:21] <lifeless> vila: a hash trie is variation of a trie
[13:21] <jam> you can build the next without doing O(tree)
[13:22] <jam> lifeless: are you even really proposing a "hash trie" ? I thought it was just a trie using paths and file_ids as the keys
[13:22] <jam> not the hashes of those
[13:23] <vila> yet 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] <vila> If I'm wrong on that point, then forget the related remarks in my review :)
[13:23] <lifeless> jam: I'm investigating the properties of several designs
[13:24] <lifeless> jam: one is a radix tree of the hashes of the file ids
[13:25] <lifeless> one is a plain radix tree
[13:25] <lifeless> on the full paths of the entries
[13:26] <lifeless> another is directory based, with large directory decomposed into internal trees
[13:30] <jam> vila: I think what you call "hash tree" lifeless calls "recursive validators" which he plans for any of them
[13:30] <jam> CHK == content hash key
[13:30] <jam> So the individual pages are referenced
[13:30] <jam> based on their content hash
[13:31] <jam> lifeless: so why use hash(file_id) just to get a more even distribution?
[13:31] <vila> jam, lifeless: CHK haaa, then the document needs to define the term
[13:31] <jam> vila: "validator(x)" is generally just secure_hash(x)
[13:31] <jam> he mentioned it earlier
[13:31] <jam> I don't know if it missed the last draft
[13:32] <jam> Who just built and uploaded the windows installers?
[13:33] <jam> Did Markh do it overnight?
[13:33] <markh> not over my night ;)
[13:33] <jam> I just see "TommiVainikainen" updating the wiki, which isn't a name I recognize
[13:33] <markh> over my day tho, yeah
[13:33] <jam> thanks markh
[13:33] <jam> Just make sure to make a note of it :)
[13:33] <markh> I did rc5 and noone complained it didn't work for them, so I figured it was good to go!
[13:34] <markh> where? :)
[13:34] <LarstiQ> hehe :)
[13:34] <markh> I'm afraid noone pointed out a process I should follow - martin just said "upload it there" :)
[13:34] <markh> hi LarstiQ!
[13:35] <LarstiQ> heya markh
[13:35] <jam> markh: well, sending an email to the list is reasonable, updating http://bazaar-vcs.org/Download and WindowsDownload
[13:35] <LarstiQ> markh: I've still got to figure out that list of music for you, it's pending, sorry :/
[13:35] <jam> also, I linked a bug to you yesterday
[13:35] <jam> someone filed a complaint that the installers took longer than a day to build...
[13:35] <LarstiQ> what?
[13:35] <LarstiQ> as in, start the build, and wait for a day?
[13:36] <LarstiQ> Or are they complaining the installers are uploaded a day after the release?
[13:36] <LarstiQ> If so, pssh.
[13:36] <jam> bug #261614
[13:37] <lifeless> jam: hashes give a homogenous fan out, which is good
[13:37] <jam> not sure whether to mark it Invalid because it isn't a bug, or Fix Released because we have the installers
[13:37] <jam> I went with Invalid for now
[13:37] <markh> jam: so I'm in trouble for not doing it fast enough, or not waiting long enough to follow the correct processes? ;)
[13:37] <jam> markh: well, I feel like reporting a bug for it, versus just an email/request is a bit ... excessive
[13:38] <jam> markh: I just didn't have anything alerting me that it happened
[13:38] <markh> jam: right, yeah, I agree - but you know users - we have nothing better to do than serve them :)
[13:38] <markh> yeah - we probably need a slightly more formal process, and I'd be happy to follow it
[13:40] <markh> I 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 time
[13:40] <jam> markh: Well "doc/developers/releasing.txt" is my checklist for tarballs, and ".../ppa.txt" is what I use to make debs
[13:40] <jam> markh: I'm fine with a 1-2 day turnaround
[13:40] <lifeless> jam: 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] <jam> We could certainly create a "windows_installer.txt" file and put it in there
[13:41] <lifeless> so capping the key length reduces the constant
[13:41] <jam> lifeless: It would be interesting to do comparisons between hash(file_id) and file_id
[13:41] <jam> as one allows a bit of grouping
[13:41] <jam> Which may or may not give locality of reference
[13:42] <jam> also, bzr's default algorithm for file ids is
[13:42] <jam> NAME-DATE-RANDOM-COUNTER, where DATE-RANDOM is fixed for everything during one "bzr add"
[13:42] <jam> which probably means you just end up with a long string that doesn't help, because NAME has already messed up your common prefix
[13:45] <lifeless> jam: right
[13:45] <lifeless> jam: thats one reason I am looking at hashed file ids as keys
[13:46] <jam> Yeah, I wonder if the 1/256 fan-out is going to be optimal in all cases
[13:46] <lifeless> a CHK pointer
[13:48] <lifeless> a kind
[13:48] <lifeless> say another 4 bytes
[13:48] <lifeless> so 45-50 bytes per pointer
[13:49] <jam> would you use binary/hex/base64 for the serialized key?
[13:49] <lifeless> for now, lets say yes
[13:49] <jam> :)
[13:51] <gimaker> add benchmarking of different trie-types, and will have lots of fun benchmarking a billion different combinations :p
[13:51] <lifeless> jam: say 50bytes per ref
[13:52] <jam> lifeless: and 256 refs per node?
[13:52] <lifeless> 256 way fan - 12K
[13:53] <jam> lifeless: 256-way fan out... gives 16.7M in 3 levels
[13:53] <jam> its what we saw with b-trees
[13:53] <lifeless> jam: yes
[13:53] <jam> it takes a *lot* of keys to hit a 3rd level
[13:53] <lifeless> which is fine
[13:53] <jam> (and there it is more like 100-way)
[13:53] <lifeless> because we don't need 256 way fan out
[13:53] <lifeless> where there are no children, we trim
[13:53] <lifeless> a wider prefix in a node - less fan out (counter-intuitive, but true)
[13:53] <jam> lifeless: Sure, but I wonder if hash() is going to tend to enforce it
[13:54] <abentley> jelmer: I don't understand why the shell script I provided wasn't sufficient to register it as a mime type handler.
[13:54] <lifeless> only the very root nodes will be so dense; and it may be we want to optimise for a smaller root page size
[13:55] <jam> it makes me *wonder* if we would rather have a node pointer for [a-c] => THIS_PAGE
[13:55] <jam> but then it isn't strictly a radix tree
[13:55] <lifeless> OTOH 12K per commit isn't impossible to handle with, if we also are compressing those nodes
[13:55] <lifeless> jam: we need a well defined canonical form
[13:56] <lifeless> jam: well, look closely at the fan out rules; I think we cam make the description more clear with a bit of effort
[13:57] <lifeless> I think the current rules may be very pleasantly surprising
[13:59] <lifeless> also, give that toy I sent you a spin
[14:02] <jam> will do
[14:02] <Ng> how 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 avail
[14:03] <jam> Ng: with 1.6 or bzr.dev, lp: or bzr+ssh: should work (earlier ones you need to use sftp://bazaar.l.n)
[14:03] <jam> However, once you've upgraded it leaves a 'backup.bzr' directory
[14:03] <jam> which may be in the way for another upload
[14:03] <jam> s/upload/upgrade
[14:03] <Ng> jam: is that roughly a suggestion that I not do it? ;)
[14:04] <jam> Ng: well, you have to delete the backup.bzr directory, and LP doesn't give you an easy way to do it
[14:04] <jam> You can use an sftp program that lets you do recursive delete
[14:04] <jam> Ng: I highly recommend that you do, just letting you know where it may fail
[14:04] <jam> rather than telling you "do X" and having you come back with "X failed"
[14:05] <Ng> jam: fair enough, thanks :)
[14:05] <lifeless> hitchhiker will let you delete it now
[14:06] <lifeless> as the launchpad sftp server doesn't work with lftp recursive delete
[14:07] <Ng> hitchhiker?
[14:07] <lifeless> yes
[14:08] <jam> Ng: it is a program written by abentley to act like an "sftp/bzr+ssh/etc" client by using the bzrlib Transport code
[14:08] <Ng> ah
[14:08] <jam> not a particularly *good* ftp/sftp client, but the *best* bzr+ssh:// client available :)
[14:09] <abentley> jam: :-)
[14:10] <jam> abentley: wasn't that even your tag line
[14:10] <jam> abentley: does hitchhiker use get_transport() such that "lp:foo" should work, as well as ":parent" ?
[14:10] <abentley> jam: Okay...
[14:10] <abentley> abentley: :-)
[14:11] <abentley> jam: Yes, lp: specs and all plugins should work.
[14:19] <vila> hmm, bitten by bug #225020, hard. Even bzr.dev exhibits the bug
[14:19] <jam> vila: bite back
[14:19] <jam> or apt-get remove pycurl
[14:19] <jam> I've been happily using your urllib code for a long time now
[14:20] <vila> I intend too, this bug seems hard to reproduce and pycurl have been removed from pqm for lack of reproducing and fixing it
[14:20] <vila> s/too/to/
[14:20] <jam> well, IIRC spiv could reliably reproduce it just by installing pycurl
[14:21] <vila> Regarding urllib/pycurl I doubt we can just drop https certificate validation
[14:22] <vila> depending on the branch I run selftest the first failing test is different...
[14:23] <vila> and of course running the tests alone make them pass
[14:29] <jam> vila: well, I would just create a http stress test
[14:30] <jam> just GET the same URL repeatedly
[14:30] <jam> (It certainly sounds like a plain bug in pycurl)
[14:30] <jam> vila: though it may be a POST issue
[14:31] <vila> that or leaked sockets
[14:31] <jam> well, all of the reported bugs are about POST
[14:31] <jam> And I could imagine that POST code gets less testing than GET code
[14:32] <jam> You might also consider that these may be a 404 on POST
[14:36] <jam> as a side question, if you have a DFA, do you usually represent that as a 2D table in memory? Or do you collapse it somehow
[14:37] <vila> jam: is that for me ? what is a DFA ?
[14:37] <jam> Deterministic Finite Automata
[14:37] <jam> or automaton
[14:37] <jam> I was reading about Trie's and they link over to DFA's
[14:38] <jam> http://en.wikipedia.org/wiki/Deterministic_finite_automaton
[14:38] <jam> I've heard about them before, but never dug deep into them.
[14:40] <lifeless> uhm
[14:40] <lifeless> there are a bunch of DFA representations
[14:41] <lifeless> in parsing its  often a graph
[14:41] <vila> Well, 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:42] <vila> otherwise most of the time I use them through scanner and parser generator which compress the tables heavily
[14:43] <lifeless> vila: used antlr?
[14:44] <vila> lifeless: 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 end
[14:45] <vila> I even port lex/yacc sources on DOS and Mac OS 7 (or 6 ?) :D
[14:45] <lifeless> I've written a dirstate antlr3 grammar
[14:45] <lifeless> well, most of
[14:47] <vila> lifeless: and your feedback is ?
[14:48] <lifeless> mmmm
[14:48] <lifeless> C runtime is immature
[14:48] <lifeless> rest is out on judgement still
[14:48] <lifeless> oh, and I hate lexers
[14:48] <lifeless> lexers are the universes way of punishing us for parses that are too slow
[14:49] <jam> lifeless: so, of course, you need to answer the question... is it *faster* ?
[14:49] <vila> Hmm, I've seen parsers suffer really badly from bad scanners, but that's more the exception than the rule IME
[14:51] <vila> of 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] <vila> i.e the parsing itself was in the noise compared to the associated semantics
[14:51] <lifeless> vila: my point is I don't like writing scanners
[14:51] <lifeless> '0-9' for instance can match far to much
[14:52] <lifeless> foo01
[14:52] <lifeless> valid path
[14:52] <vila> lifeless: ok, that's different then, but years of perl experience tend to help here too :)
[14:52] <lifeless> also matches 01 if you don't force a whitespace in the scanner
[14:53] <lifeless> worse, consider whole numbers vs ints
[14:55] <ryanakca> I'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:59] <jam> ryanakca: you have bzr-svn installed, and a containing .svn directory
[14:59] <lifeless> vila: I'll reply tomorrow
[14:59] <jam> so the branch command seems to be trying to re-use it
[15:00] <vila> lifeless: are you still in AU, your hours seems unusal ?
[15:00] <jam> But there is something odd in that bzr-svn is actually unable to open your .svn directory
[15:00] <ryanakca> jam: svn: warning: '.' is not a working copy
[15:00] <jam> ryanakca: short answer, disable bzr-svn
[15:00] <jam> longer answer
[15:01] <ryanakca> jam: how can I disable plugins during a command ?
[15:01] <jam> bzr 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:02] <jam> ryanakca: 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] <ryanakca> jam: ah. ok, thanks. But why would it try to open /home/ryan if I'm trying to branch in /home/ryan/work/ ?
[15:03] <jam> ryanakca: We search for a possible shared repository in containing directories
[15:03] <jam> you could do "bzr init-repo ~/work" and then we would find that one instead
[15:03] <Freaky> hm, 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] <ryanakca> jam: thanks
[15:03] <jam> Freaky: I'm pretty sure the stored form is supposed to be the same.
[15:04] <jam> It is more of a config flag
[15:05] <Freaky> I'm doing a bzr upgrade, the original .bzr is 211MB, the new one is 259MB and still growing after 85 minutes
[15:06] <Pieter> it's creating a new pack file for your upgrade
[15:06] <Pieter> you can delete the old files afterwards
[15:06] <Pieter> so the growth is just temporary
[15:07] <Freaky> ah, repository is 48MB, repository.backup is 210MB
[15:07] <Freaky> and it should grow to be roughly the same?
[15:08] <Pieter> who knows?
[15:08] <Peng_> Freaky: Probably. Wait and see. :)
[15:09] <Freaky> be waiting a long time then ;)
[15:37] <gour> bzr-svn-0.4.11 is released?
[15:37] <jam> gour: yes, it should be in the ppa
[15:38] <jam> I don't think jelmer gave an official announcement
[15:38] <jam> but he created the tag and published it to debian
[15:38] <jam> and had me publish it to bzr-ppa
[15:40]  * gour is on archlinux
[15:40] <gour> great...no more svn :-)
[15:40] <jam> there should be a tarball somewhere
[15:41] <gour> i got it. ta
[15:41] <gour> it's here http://samba.org/~jelmer/bzr/bzr-svn-0.4.11.tar.gz
[15:55] <rocky> here'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:56] <LarstiQ> rocky: I _think_ so, but I haven't tried it.
[15:57] <luks> it's perfectly safe, people are using even repositories on usb sticks and more them between computers
[15:57] <luks> *move
[15:57] <rocky> oh yeah? now that's interesting
[16:13] <gour> jelmer: thank you for 0.4.11
[16:14]  * gour is doing his first fetch of svn repo via bzr-svn
[16:15] <gour> hmm bzr crashed - http://rafb.net/p/dkYRIG77.html
[16:16] <gour> am i doing something wrong?
[16:17] <jelmer> gour: no, that should work fine
[16:18] <jelmer> gour: did this work previously?
[16:19] <gour> jelmer: dunno. my first fetch from the repo and first use of bzr-svn plugin
[16:20] <jelmer> gour: please file a bug
[16:20] <gour> jelmer: for bzr?
[16:20] <jelmer> gour: bzr-svn
[16:20] <gour> ok
[16:21] <jelmer> gour: it could be a serverside thing as well, google's svn may not like how we're using it
[16:22] <dlee> This just happened to me; wondering if it's worth worrying about:
[16:23] <dlee> BZR 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] <dlee> It 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:24] <dlee> I think Windows ignores the trailing space on file creation.  Interestingly, bzr diff shows "remove file" but no diff contents.
[16:24] <dlee> If you actually remove the file, you get the listing of contents per usual.
[16:24] <gour> jelmer: https://bugs.launchpad.net/bzr-svn/+bug/261878
[16:25] <dlee> Theory:  This means Windows matches the file during that process too; it just can't make the name match.
[16:26] <jelmer> gour: thanks
[16:27] <dlee> I'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:28] <jelmer> dlee: you should be able to just remove the trailing whitespace in unix
[16:28] <jelmer> dlee: commit then and then update in windows
[16:29] <jelmer> dlee: 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 names
[16:29] <dlee> True, 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:30] <dlee> But 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] <jelmer> dlee: please file a bug
[16:31] <dlee> will do.
[16:31] <jelmer> dlee: We do plan on warning when you add a file that can't be checked out properly on other platforms
[16:32] <abentley> jelmer: We don't deliberately refuse to check out any files on Windows, and I don't think we should.
[16:33] <jelmer> abentley: some files simply can't be checked out on Windows because of their name
[16:33] <abentley> jelmer: I think we should handle it as a conflict.
[16:33] <jelmer> abentley: that's an interesting thought
[16:33] <abentley> jelmer: So we check them out with a different name, and tell the user what we did.
[16:34] <abentley> jelmer: That way, Windows users (who are the only ones likely to care) can fix such problems themselves.
[16:34] <jelmer> abentley: yeah, that's nicer indeed than having to go back to unix to fix it there..
[16:35] <rocky> jelmer: as you might imagine, bzr-svn over dial-up is useless ;)
[16:36] <rocky> that is, push commits and the like to the remote svn using bzr-svn over dial-up is useless ;)
[16:36] <dlee> As 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:37] <jelmer> abentley: I would really like to see a warning system on unix rather than forbidding certain characters
[16:37] <abentley> jelmer: I'd like that, too.
[16:38] <jelmer> rocky: yeah, I wouldn't attempt to do that (yet)
[16:39] <jelmer> rocky: what will help is having only one svn repo per project
[16:39] <LarstiQ> there was a time when you couldn't even make a branch of something that had a revision with 'con.txt' in the inventory
[16:39] <jelmer> LarstiQ: ah, the good old days
[16:39] <LarstiQ> yes, very fun.
[16:39] <rocky> jelmer: well ... that's mostly what i do, but that "project" sometimes has several sub-projects
[16:39] <jelmer> rocky: yeah, the subprojects is what I mean
[16:39] <LarstiQ> abentley: excellent idea on the conflict for such a situation btw
[16:40] <rocky> jelmer: having to create a separate svn repo for each subproject is a bit overkill on these projects i'm working on ;)
[16:40] <jelmer> abentley: oh btw
[16:40] <jelmer> abentley: bzr-handle-patch.sh relied on something being in "/home/abentley"
[16:41] <jelmer> abentley: so instead of fixing the shell script I just changed it to use python directly
[16:42] <abentley> jelmer: Removing a command seems like a rather extreme way to fix that.
[16:43] <jelmer> abentley: wasn't the command just for internal use (by mime-type handlers and the like) anyway?
[16:44] <jelmer> abentley: If it's not, I misunderstood and we should look at reintroducing it.
[16:44] <abentley> It's not just for internal use.
[16:45] <jelmer> abentley: Sorry
[16:45]  * gour is fetching from another svn repo
[16:45] <jelmer> gour: works better this time 'round?
[16:46] <rocky> jelmer: 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] <jelmer> rocky: afaik bzr won't let you create a checkout of a checkout, but I'm not entirely sure
[16:46] <LarstiQ> it will.
[16:46] <abentley> It was meant to be a regular Bazaar command.  With a wrapper because mime-type mechanisms are so primitive.
[16:47] <gour> jelmer: it is still copying...unfortunately, i've cinelerra's rendering job in the background, that's why it's going slower
[16:47] <loxs> hello. 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:48] <gour> loxs: part of repo or one branch?
[16:49] <jelmer> LarstiQ: what will it do when you commit though?
[16:50] <loxs> gour, 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 path
[16:51] <jelmer> loxs: ah, you mean partial checkouts
[16:51] <jelmer> loxs: (in bzr terminology)
[16:51] <loxs> yes jelmer, that's very easy with svn
[16:51] <jelmer> loxs: they're planned but not implemented yet
[16:52] <gour> loxs: see http://bazaar-vcs.org/SharedRepositoryLayouts?highlight=(layouts) as well
[16:55] <loxs> nah, gour, you say I need a different philosopy ;) i like this kind of answers :)
[16:56] <rocky> don'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:57] <gour> loxs: 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 Python
[16:58] <awilkins> rocky: 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] <dlee> jelmer:  Filing as a comment to bug 3918
[16:59] <jelmer> dlee: thanks!
[16:59] <rocky> awilkins: well, this is merging using bzr-svn which i don't think will track that info in the svn log
[16:59] <awilkins> rocky: Fair do's
[16:59] <jelmer> rocky: if you have svn 1.5, bzr-svn will store the merge info
[17:00] <jelmer> rocky: that should allow svn ("svn log -g" I think) to display what revisions were merged
[17:01] <rocky> jelmer: i had to revert to svn 1.4 unfortunately ... mostly because of setuptools inability to deal with svn 1.5 properly
[17:01] <loxs> hm, 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] <jelmer> rocky: how do you mean?
[17:01] <jelmer> rocky: setup.py in bzr-svn?
[17:02] <rocky> jelmer: 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 setuptools
[17:02] <gour> loxs: i wasn't speak about python projects, but in general considering how svn projects are laid out
[17:03] <jelmer> rocky: ahh, ok
[17:03] <rocky> several bugs
[17:03] <rocky> jelmer: and stuff where setuptools will inspect files and auto-include them with "setup.py sdist" fails with svn 1.5 checkouts
[17:03]  * Odd_Bloke is getting http://paste.ubuntu.com/40944/ when trying to run bzr-svn trunk with bzr.dev.
[17:04] <Odd_Bloke> Anyone know what's going on?
[17:04] <rocky> so, i've reverted back to svn 1.4.6 since i have no good reason to upgrade to 1.5 anyways
[17:04] <jelmer> Odd_Bloke: you need to build bzr-svn
[17:05] <jelmer> back in ~30min
[17:05] <Odd_Bloke> jelmer: Anything more than 'make'?  Because I've done that.
[17:08] <Odd_Bloke> jelmer: NM, there were a number of weird interactions going on.
[17:08] <Odd_Bloke> Fixed now. :)
[17:54] <loxs> I 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:55] <luks> perhaps a terminology issue, but by 'working tree' you mean a bzr working tree?
[17:55] <loxs> sure, luks
[17:56] <luks> well, technically you can't put branches inside branches, but I don't think it's a good idea
[17:56] <luks> er, can, not can't
[17:57] <luks> if this is a single package, it should be a single branch, IMO
[17:57] <loxs> well, the reason I want this thing is because of the lack of partial checkouts in bzr
[17:57] <luks> and normally you put the package into a directory, not to the root
[17:58] <loxs> and I want to update my server from the repository
[17:58] <luks> loxs: but then you lose the ability to checkout the whole package
[17:58] <luks> if it's split into several branches
[17:58] <loxs> I dont' get what you mean
[17:59] <luks> let's say you have myproject/trunk and myproject/trunk/subpackage where both trunk and trunk/subpackage are separate branch
[18:00] <loxs> no, i don't want that
[18:00] <luks> then by running "bzr branch myproject/trunk" you will not get myproject/trunk/subpackage
[18:00] <luks> oh
[18:00] <loxs> I mean the following:
[18:00] <loxs> I want project/ to be the trunk/
[18:00] <loxs> and a project/branches/ subdirectory to hold the branches
[18:02] <luks> ah, that's not a problem
[18:02] <loxs> i 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 path
[18:02] <loxs> if there is project/trunk, then trunk is no more accessible as a python package
[18:03] <luks> I meant that project/trunk/ is a branch
[18:03] <luks> not that you have a branch project/ with a directory trunk/ in it
[18:03] <loxs> I will not have a trunk/ directory at all... the root of the project will be the trunk
[18:03] <loxs> is it ok?
[18:04] <luks> yes, location of branches usually doesn't matter in bzr
[18:06] <loxs> and do you think it is a good practice luks?
[18:08] <luks> loxs: well, I personally wouldn't put the package root to a root of a branch
[18:08] <rocky> are there any other deployments for bundle buggy out there other than the bzr one at aaronbentley.com
[18:08] <luks> because then it's harder for me to do setup.py and other things
[18:09] <luks> (if by package you meant a python package)
[18:09] <luks> ah, yes
[18:09] <loxs> you say  you would prefer to use setup.py and install from the repository instead of using the program from the repository directly?
[18:10] <luks> depends on the situation, but I prefer all python packaged to have setup.py
[18:10] <loxs> it's a django site
[18:10] <luks> if you want to use the working tree for deployment, I'd probably just symlink it
[18:10] <loxs> hm, yes, it's probably a good idea too...
[18:11] <luks> I don't know what's the usual layout of django projects
[18:11] <luks> but I would be surprised if they had python files in the root directory
[18:12] <loxs> the thing there is that there are quite a lot of non-python files that have to be used... html, css etc.
[18:12] <luks> there must be templates, some static files, maybe some unrelated data files and scripts
[18:12] <luks> exactly
[18:12] <loxs> but the main part is a python package
[18:12] <loxs> that must be on the python path
[18:12] <luks> is this for develoment or production deployment?
[18:13] <loxs> deployment
[18:13] <loxs> for development there is a dev server that does'nt care where it is... it is run via a script from the project
[18:14] <loxs> but for deployment the project is called via mod_python and it must be in the python path
[18:14] <luks> you can modify sys.path from mod_python
[18:14] <luks> so I'd point it to the working tree
[18:14] <loxs> I know, but I sill prefer to have my project in site-packages
[18:15] <loxs> and I planned to have a cron job to sync the repository there
[18:15] <luks> then a symlink, I don't like the idea of mixing python code with data files in the same directory
[18:15] <loxs> yes, I'll probably go with a simlink
[18:16] <loxs> thank you for the conversation :)
[18:16] <luks> np, I like having these kind of conversations :)
[18:17] <loxs> and what is your personal preference for a repository layout?
[18:17] <loxs> i read this http://bazaar-vcs.org/SharedRepositoryLayouts?highlight=(layouts) and can't choose :)
[18:18] <luks> I like a flat list of branches in the repository
[18:18] <luks> so repo/trunk/ repo/branch1/ etc.
[18:18] <luks> and separate repositories for separate projects
[18:18] <loxs> you mean the good old svn style? :)
[18:19] <luks> no, svn does repo/trunk/ repo/branches/branch1/
[18:19] <luks> I don't like the branches/ directory
[18:19] <loxs> aha, I see
[18:19] <loxs> doesn't it get quite cluttered then?
[18:20] <luks> I delete branches after they are merged, so it doesn't
[18:21] <loxs> I need some place where inexperienced "wannabeadeveloper"s make their own little chaos :)
[18:21] <loxs> so probably I'll go with something like developer/whatever he chooses/
[18:40] <jelmer> luks, where do you put tags then?
[18:40] <luks> jelmer: bzr tag :)
[18:41] <jelmer> luks, ah, I thought you were talking about your preferences for svn (-:
[18:42] <luks> I wouldn't dare to delete svn branches
[18:42] <luks> even with the 1.5 merge tracking
[18:43] <mpt> Heeeeeeelp ... 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:44] <jam> mpt: which branch
[18:44] <mpt> (After the previous failed attempt I replaced .bzr with the backup.bzr it had made when it started.)
[18:44] <mpt> jam, no branch in particular, this is at the project level
[18:45] <mpt> Do I need to do it for each branch separately?
[18:45] <jam> mpt: sure, I was just hoping to poke at it and make sure
[18:45] <jam> is it somewhere I could get to it?
[18:50] <jelmer> jam, any chance you can comment on https://lists.ubuntu.com/archives/bazaar/2008q3/046309.html ?
[18:51] <jam> It doesn't seem like enough of anything to really comment on
[18:54] <jelmer> jam: Ok, no objections to it though?
[18:54] <jam> No specific objections, though your VCSMapping object is just information about the mapping, it doesn't do any actual mapping
[18:56] <_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:58] <jelmer> jam: That's all implementation-specific, this is just infrastructure shared between bzr-git and bzr-svn
[18:59] <jam> _stink_: well, it looks like the ssh connection is failing. you could try: bzr branch lp:sendoff -Derror
[18:59] <jam> which gives a  full traceback
[18:59] <jelmer> I wanted to check before I did any more work on this, since I was a bit surprised when my VirtualSignatureTexts patch was vetoed
[18:59] <jam> jelmer: well VST was an inversion of layering
[18:59] <jam> which was a bit odd
[19:00] <jam> For your Mapping stuff, it doesn't seem like a problem, but it also doesn't seem to provide much yet
[19:00] <jam> so perhaps at least a little discussion about why you want to use it, and how
[19:00] <mpt> thanks muchly for your help, jam
[19:00] <jam> np mpt
[19:00] <jam> happy to help
[19:00] <_stink_> jam: http://paste.ubuntu.com/40968/ for output with -Derror
[19:01] <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] <jam> you just have to use sftp because launchpad only allows bzr+ssh or sftp
[19:03] <_stink_> jam: http://paste.ubuntu.com/40969/ still publickey connection error.
[19:04] <jam> _stink_: you should be able to do "sftp -v"
[19:05] <jam> It sounds like something between you and LP is preventing you from connecting
[19:06] <_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. thanks
[19:15] <tethridge> if 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] <tethridge> I'm not sure if that is an acceptable thing to do
[19:15] <luks> yes, it will be
[19:16] <luks> and if there is a reason why it can't be, bzr will complain
[19:16] <luks> (complain and not perform the push)
[19:16] <tethridge> that's cool
[19:16] <tethridge> I would like to think that it would work that way, but not all software "just works"
[19:28] <jaypipes> jam: query window...
[19:36] <pickscrape> Would I be right in thinking that bzr bundle is the same as bzr send without the mail client integration?
[19:40] <james_w> pickscrape: yes, you would
[19:40] <pickscrape> james_w: thanks, it's just what I'm after :)
[19:41] <luks> I don't think it is
[20:05] <abentley> pickscrape: 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:15] <abentley> james_w: Please encourage people to use bzr send.  There's nothing bundle can do that send cannot.
[20:20] <pickscrape> abentley: ooh, I had actually looked for such an option in bzr send but for some reason completely missed that one... Thanks!
[20:21] <abentley> pickscrape: no problem.
[20:47] <jelmer> abentley, do you have any idea what could be causing bug 203376 ?
[20:48] <abentley> jelmer: Which bzr version did you confirm it on?
[20:48] <jelmer> current bzr.dev and bzr 1.6
[20:49] <jelmer> Good point, I'll put it in the bugreport
[20:50] <abentley> jelmer: So, I would guess that two codepaths are causing the creation to be cancelled, but a creation can only be cancelled once.
[20:51] <jelmer> abentley: What could cause that though?
[20:51] <jelmer> abentley, the actual join worked fine and committing it also worked fine
[20:51] <jelmer> the first merge of the joined branch after that fails
[20:51] <jelmer> the merge would only change a file text, nothing else
[20:52] <jelmer> abentley, why would it need to call fix_root() in this case?
[20:52] <abentley> jelmer: look, it's a bug.  If I'd expected it to happen, I'd have fixed it too.
[20:52] <abentley> jelmer: We always call fix_root, for regularity's sake.
[20:53] <abadger1999> If 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] <jelmer> abentley: I'm just trying to understand what's happening since I'm not very familiar with this code
[20:53] <jelmer> abentley: ah, ok
[20:54] <abentley> fix_root should only have an effect when you've got a tree with two roots.
[20:54] <abentley> Join shouldn't give you a tree with two roots, it should make one tree's root into a subdir of the other.
[20:55] <abentley> I suppose you could do conflicting joins.
[20:55] <jelmer> abentley: Thanks, that helps
[20:56] <jelmer> abentley: The problem is somewhere in fix_root, skipping it fixes the problem
[20:56] <abentley> So that one tree claims that x is a subdir of y, and another tree claims x is a subdir of z.
[20:56] <Odd_Bloke> abadger1999: I'd suggest mentioning this on-list, if you haven't already.
[20:56] <abentley> That would cause merge to give you a tree with two roots.
[20:57] <abentley> But it's actually intended for the case where you're merging two unrelated trees.
[20:57] <jelmer> abentley: the problem appears to be that merging another branch whose root is not the root of the tree we're merging into breaks things
[20:58] <jelmer> not the root of the tree we're merging into, but present as regular directory in that tree
[20:58] <abadger1999> Odd_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:59] <abadger1999> So I thought I'd start here.
[20:59] <jelmer> abentley: I think I know enough now anyhow to try and get this fixed
[20:59] <jelmer> abentley, thanks!
[21:01] <abentley> jelmer: You're welcome.
[21:16] <james_w> jelmer: hey, did you send me your merge-upstream changes?
[21:16] <jelmer> james_w, No, I requested merges in lp
[21:17] <jelmer> james_w, I'm happy to send them to you as well if you prefer
[21:17] <james_w> ah, I'm obviously not subscribed
[21:17] <james_w> I can look
[21:17] <james_w> I've just completely re-written the code though, sorry
[21:17] <jelmer> james_w, where's your code these days?
[21:18] <jelmer> Last change I see here is from quite a while ago
[21:18] <james_w> yeah, it's been in flux for a long while
[21:18] <james_w> bzr+ssh://bzr.debian.org/bzr/pkg-bazaar/bzr-builddeb/2.0
[21:19] <james_w> your change will still apply, but have no effect, I haven't deleted the unused code yet
[21:19] <james_w> wow, you have been busy
[21:22] <james_w> so, you want it to degenerate to "bzr merge" sensibly, but do some other things as well?
[21:22] <jelmer> yeah, with all that packaging I did I used bzr-builddeb a lot :-)
[21:22] <jelmer> james_w: Yeah, basically "bzr merge" and figure out the new Debian upstream version string
[21:23] <james_w> I'd like to leave these out of this release
[21:23] <james_w> it's already huge, and I need to get it done in the next hour or two
[21:23] <james_w> I can merge then straight after though
[21:24] <james_w> well, not *straight* after, I'd like some sleep :-)
[21:24] <jelmer> james_w: No problem
[21:24] <jelmer> james_w: Are you interested in conflict-free versions of these branches?
[21:24] <james_w> no, that's fine
[21:24] <james_w> it will be far more work for you to understand the new code than for me to make your changes to it
[21:25] <james_w> I would love it if you could test that branch for a few of your usual operations though.
[21:25] <james_w> the 2.0 branch I mean
[21:27] <jelmer> sure
[21:27] <jelmer> Any commands in particular?
[21:27] <james_w> builddeb has changed a couple of default locations
[21:27] <james_w> i.e. .. instead of ../tarballs and the results end up in .. as well
[21:28] <james_w> but it should fall back for the first, and not break too much for the second
[21:28] <james_w> merge-upstream and import-dsc have been completely re-written, so anything you can do with them would be great.
[21:29] <jelmer> builddeb itself is still doing the right things wrt paths
[21:31] <james_w> good
[21:32] <james_w> these changes set us up much better for the future.
[21:32] <james_w> siretart: hi, sorry it's late, are you still around?
[21:35] <jelmer> james_w, I can't find anything otherwise wrong doing some simple tests
[21:36] <Odd_Bloke> I 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_w> jelmer: good to know, thanks. The test coverage has dropped a bit recently, so there could have been holes.
[21:36] <jelmer> Odd_Bloke, yes, you'll have to remove that directory and push using svn-push
[21:37] <Odd_Bloke> jelmer: Thanks. :)
[21:45] <loxs> folks, is there a way to make bzr write some "standard stuff" in the beginning of all of my files?
[21:46] <LarstiQ> loxs: keyword expansion I suppose?
[21:47] <loxs> LarstiQ, i have no idea what is this, where is it in the docs?
[21:48] <loxs> i found it, thank you
[21:48] <jelmer> james_w, one comment
[21:49] <jelmer> james_w, any chance target_distribution and version can be options rather than arguments to merge-upstream?
[21:49] <james_w> why's that?
[21:49] <jelmer> james_w, That makes it a lot easier to make either optional
[21:49] <james_w> ah, for the later work?
[21:49] <jelmer> yeah, if it ends up in a release now it's going to hurt more people if it's changed later
[21:50] <james_w> yeah
[21:50] <james_w> they are at the end, so you can drop them off without breaking things
[21:50] <james_w> though they are probably the wrong way round for that
[21:51] <james_w> doing it now
[21:51] <jelmer> james_w, yeah, though I can also imagine target_distribution being optional (perhaps default to the distro the user is running?)
[21:52] <james_w> perhaps
[22:07] <ronny> how can i pull a single revision from one branch into another for merging?
[22:07] <Odd_Bloke> ronny: 'bzr merge -c <revspec> <source>'
[22:14] <acemo> when 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] <LarstiQ> acemo: is LANG/LC_CTYPE one of such set to something the system doesn't have?
[22:14] <LarstiQ> acemo: see `locale` output
[22:15] <acemo> its UTF-8
[22:17] <LarstiQ> acemo: that should be fine
[22:17]  * LarstiQ falls asleep
[22:17] <LarstiQ> acemo: you could look at ~/.bzr.log
[22:18] <ronny> hmm, why cant i just pull revs from other branches into a branch ?
[22:19] <acemo> LarstiQ: http://rafb.net/p/gWsCmO64.html heres my ~/.bzr.log
[22:27] <jdobrien> LarstiQ: re: bug #31059 it will be a while before i can get back to it
[22:27] <jdobrien> LarstiQ: er bug #30159
[22:30] <ronny> whats the name of the extension for graphical logs?
[22:30] <awilkins> ronny: 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:31] <awilkins> ronny: qbzr and bzr-gtk both provide graphic logs
[22:31] <awilkins> ronny: qbzr has the superior log view in most people opinions
[22:32] <ronny> awilkins: in my case they have the same ancestery, but bzr just errors telling me to use merge instead
[22:33] <awilkins> ronny: Have you committed revisions that the merge source does not have?
[22:33] <ronny> yeah
[22:34] <awilkins> ronny: 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] <ronny> i dotn see what should prevent a pull tho, it would just add a new head
[22:35] <awilkins> Rebase would be what you are aiming at ;; "just insert the revisions from the other branch before my new ones"
[22:35] <awilkins> Not a good idea if you've pushed it elsewhere though
[22:35] <ronny> but i just want to do get the revs into my branch, ONLY that
[22:35] <awilkins> ronny: You want to get rid of your new revisions?
[22:35] <ronny> no
[22:36] <awilkins> Then you merge, or you rebase
[22:36] <awilkins> Merge does only merge the revisions you need
[22:36] <awilkins> ronny: Are you an existing SVN user?
[22:36] <ronny> no
[22:36] <ronny> monotone, git, mercurial
[22:36] <acemo> is bzr 1.6 on mac still having the problems with utf-8?
[22:37] <ronny> they all allow me to do what the heck i want, bzr is the only one getting into my way
[22:38] <jelmer> james_w, --snapshot went away?
[22:39] <james_w> jelmer: yeah
[22:39] <james_w> it was completely broken by snapshot.debian.net dying
[22:39] <james_w> and I hadn't ported it to the new code, and it didn't seem worth it when there was nothing to get the packages from
[22:39] <james_w> it will come back when there is a new service
[22:40] <jelmer> ah, ok
[22:40] <jelmer> pity, I didn't know snapshot.debian.net had died
[22:40] <jelmer> I never used --snapshot, just noticed that the arguments list had gotten shorter :-)
[22:40] <james_w> yeah, apparently they ran out of diskspace
[22:40] <james_w> it's going to become an official debian service
[22:41] <james_w> and hopefully that will still have all the history
[22:45] <fullermd> ronny: Er, AFAIK, both git and hg will have the same behavior as bzr (though commands may be named differently).
[22:46] <fullermd> ronny: 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:47] <ronny> fullermd: 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 ever
[22:47] <fullermd> Yes, but if they're different refs, they're not in the branch.  They're different branches (or pseudo-branches)
[22:48] <ronny> in hg its valid in the same branch
[22:48] <jam> fullermd, 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 revisions
[22:48] <jam> which causes multi-heads in hg
[22:48] <jam> and another branch pointer in git
[22:48] <jam> in bzr terms
[22:48] <jam> it would be "bzr branch other" into a shared repository
[22:48] <jam> to get the same behavior
[22:49] <ronny> for me thats just an unacceptable workflow enforcement
[22:58] <clemente>
[22:58] <clemente>
[22:58] <clemente>
[22:58] <clemente>
[22:58] <clemente>
[22:58] <lifeless> clemente: I see blank lines
[22:59] <clemente> lifeless: sorry, problems with my client. Hopefully I didn't send hundreds of lines a moment ago
[22:59] <lifeless> only 5 :)
[23:01] <clemente> Ok, so if you paste hundreds of lines, apparently you get kicked by the server :-)
[23:01] <awilkins>  -!- clemente<EMAIL_ADDRESS>has quit [Excess Flood]
[23:02] <clemente> I won't do it again
[23:03] <ronny> is there any way to go to a previous version?
[23:04] <uws> ronny: Read  "bzr help revert"
[23:05] <ronny> uws: that doesnt exactly look like "go back to rev x"
[23:06] <awilkins> Your question is vague
[23:06] <lifeless> ronny: do you want your tree reverted to x, or your branch ?
[23:06] <ronny> the tree
[23:06] <uws> bzr revert -r123
[23:06] <lifeless> then revert is what you want; it changes the tree and leaves the branch untouched
[23:06] <uws> That does EXACTLY look like "go back to rev x"
[23:11] <lifeless> ronny: give it a go, tell us if its what you're looking for
[23:11] <lifeless> ronny: then, if it is, I'd like to understand why you felt it wouldn't be
[23:12] <ronny> works
[23:12] <lifeless> (and if it isn't, well, we can talk about what you really want)
[23:12] <[cliff]> hi all
[23:13] <[cliff]> is there any progress on nested tree support?
[23:13] <lifeless> not that I know of
[23:13] <awilkins> Short answer ; no
[23:14] <ronny> lifeless: looks weird, first if all i expect a revert only to change my workdir (not alter its parents or anything else)
[23:14] <awilkins> ronny: The command is global to your tree by default ; try bzr revert . -r X instead
[23:14] <ronny> second i skiped to the long text, it just talks about reseting files to the orginal stuff, and how to get rid of stuff using merge
[23:15] <lifeless> ronny: well, it hasn't changed parents
[23:15] <[cliff]> one more question: what is configmanager? how does it work? the page is kind of vague: http://bazaar-vcs.org/ConfigManager
[23:15] <awilkins> lifeless: I think he means `pwd` not `branch tree`
[23:15] <ronny> oh, it really didnt
[23:15] <ronny> sorry there
[23:16] <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 them
[23:16] <ronny> so 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:17] <lifeless> ronny: oh, so you *do* want to change the branch :)
[23:17] <ronny> ok, dammit, yet another set of terms
[23:17] <awilkins> git/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 folder
[23:17] <lifeless> ronny: 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:18] <lifeless> repository - could of history data
[23:18] <lifeless> [cliff]: it needs some love for its bzr support, 'probably' is the best answer offhand
[23:18] <lifeless> repository - cloud of history data (same meaning as git/hg/monotone/svn/cvs/etc)
[23:19] <lifeless> branch - 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 else
[23:20] <lifeless> ronny: anyhow, 'commit' adds a new revision onto a branch, updating its tip in the process
[23:20] <ronny> hg named branches may have more than one head
[23:20] <lifeless> ronny: can they? I misunderstood them then. garh, I'll go read the code later
[23:20] <lifeless> anyhow, bzr branches are an explicit pointer to a revision id
[23:21] <lifeless> to commit on a different revision than the branches tip, *either* change the tip first, *or* make a new branch with a different tip
[23:21] <lifeless> to do the former : 'uncommit -r X' or 'pull --overwrite . -r X' will do what you want
[23:22] <lifeless> to do the latter, 'bzr branch -r X . ../newbranch'
[23:22] <ronny> so i either kill later revs, or i need a new directory ?
[23:22] <uws> be careful since "uncommit" may make you lose code
[23:22] <uws> (and history)
[23:23] <awilkins> ronny: You could put your branch in a repo and use switching
[23:23] <jam> uws: no more than pull --overwrite
[23:23] <jam> uws: and with latest bzr, 'uncommit' will tell you how to get your pointer back
[23:23] <lifeless> uws: uncommit doesn't do an automatic gc
[23:23] <awilkins> You still have to make new directories for branches, but you can keep one working folder
[23:23] <uws> jam: well, pull implies there's some history elsewhere :)
[23:23] <uws> jam, lifeless: ah ok. didn't about recent developments
[23:23] <jam> uws: "bzr pull .- rXXX"
[23:23] <ronny> oh pain :(
[23:24] <lifeless> ronny: uhm
[23:24] <uws> jam: (oops, missed the . )
[23:24] <lifeless> ronny: I suspect we're seeing the tip of your needs
[23:24] <ronny> that basically killing most of my workflows
[23:24] <lifeless> ronny: 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 now
[23:25] <lifeless> because I suspect we support your work flow just fine, but its spelt a little differently than you may be used to
[23:25]  * awilkins suspects it's similar to this : http://www.g2one.com/quickcasts/movies/gitGrailsScreencast_web_final_compressed.mov
[23:26] <lifeless> awilkins: its similar to a proprietary format video?
[23:26] <fullermd> Easy creation of multiple branches/heads on the fly is handy if you're doing a lot of DAGgy-fixes'ing.
[23:26] <awilkins> THe video is one of some guy using git to rapidly switch between branches
[23:26] <lifeless> so shared repo & switch, or loom
[23:27] <awilkins> Someone posted it in here and I said the same thing
[23:27] <ronny> i dont just switch betwen branches rapidly, but also betwen different parts of the history
[23:27] <awilkins> (apart from looms)
[23:27] <lifeless> ronny: go on
[23:28] <ronny> i usualy pull from a few people at once, then just jump betwen the various revs and take a look on what to merge
[23:29] <lifeless> so, I need to translate this into raw mechanics I think
[23:29] <lifeless> you create a bunch of unmerged tips in your history store
[23:29] <lifeless> and then examine each one to see if you want to merge it
[23:29] <lifeless> and finally merge some onto your actual current branch tip ?
[23:29] <ronny> yeah
[23:30] <lifeless> ok
[23:30] <lifeless> I can tell you how I'd do this, which isn't the only way
[23:30] <lifeless> let me just pastebin a small scenario
[23:34] <lifeless> ronny: http://pastebin.com/d53f46e8
[23:34] <lifeless> ronny: this will be network and local space efficient
[23:35] <ronny> any way to turn a normal repo to something like that?
[23:36] <lifeless> the easiest way is just to branch your current tree into a shared repo
[23:36] <lifeless> but 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 hand
[23:39] <ronny> nothing big here
[23:40] <ronny> guess i could just use that
[23:40] <ronny> still puts having tonns of dirs on me
[23:40] <fullermd> Can't reconfigure do that?
[23:40] <lifeless> fullermd: probably, I haven't internalised it enough
[23:40] <lifeless> ronny: each branch dir is tiny
[23:40] <fullermd> It's got a --use-shared and --standalone.
[23:40] <lifeless> ronny: it doesn't have a checkout of your code; so its only got a pointer, and configuration data
[23:41] <ronny> lifeless: i know they are tiny
[23:41] <lifeless> ronny: ok :)
[23:41] <lifeless> ronny: uhm, is there some scaling issue with directories for you? Or its a taste thing?
[23:42] <uws> the fact that branches ARE directory helps visibility
[23:42] <ronny> its still extra management (i hate having dozens of dirs) and selecting special versions (that arent any tip) is still odd
[23:42] <uws> that helps a lot of users
[23:43] <lifeless> ronny: ok, well, it sounds like dirs are more in your face than just names in a file?
[23:45] <ronny> yeah
[23:46] <ronny> all the branches and revisions are completely irelevant to me, till i actually want to take a look/merge
[23:48] <ronny> hmm, does bzr 1.5 choke on tailing whitespace conflicts ?
[23:49] <ronny> (appearantly someone left them, and someone else has an autofix for those in the editor)
[23:50] <lifeless> oh
[23:50] <lifeless> I don't think we have a special-case flag for whitespace
[23:50] <lifeless> but if its a clean 3-way it wont' conflict anyhow
[23:51] <lifeless> or you could use --lca which will likely do a better job
[23:52] <ronny> hmk
[23:53] <ronny> at least im done with that merge now
[23:59] <fta> is 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)