[00:02] <Verterok> hi poolie
[00:06]  * AfC waves to Verterok
[00:11] <Verterok> hi AfC :)
[00:36] <lifeless> jelmer: ping
[00:36] <jelmer> lifeless: pong
[00:37] <lifeless> jelmer: re your virtual files things
[00:37] <lifeless> jelmer: I'm guessing you want to avoid code dup between bzr-git and bzr-svn ?
[00:37] <lifeless> jelmer: if so, perhaps a good staging place would be bzr-foreignformatsupport or something ?
[00:38] <jelmer> lifeless: as in a separate plugin you mean?
[00:38] <lifeless> I'm not against the things you are producing coming into the core bzr, but perhaps for other core devs the overall shape of what you are producing is not visible yet
[00:38] <lifeless> yes, as in bzr.plugins.foreignformatsupport
[00:38] <jelmer> ah, in a plugin but shipped with core?
[00:39] <lifeless> well
[00:40] <lifeless> I was actually meaning 'keep it completely separate until its more clear'
[00:40] <jelmer> I'd rather not require a separate plugin to be installed for bzr-svn and bzr-git to work
[00:40] <lifeless> we have the open bug about shipping > bzr's tree on make dist
[00:40] <lifeless> hmm, perhaps thats what I should do today
[00:40] <jelmer> that means an extra plugin to package and it means requiring users to install yet another plugin for either to work
[00:40] <lifeless> well
[00:41] <lifeless> you've got a month till 1.7 anyway
[00:41] <lifeless> so packaging would be premature right now; and I will have a poke at a dist-many thing today
[00:41] <lifeless> evolution is *still* importing :(
[00:42] <lifeless> Jc2k: how long did the full evo import take initially ?
[00:42] <awilkins> jelmer: Has bzr-svn -.4 moved much in the last week ?
[00:42] <lifeless> poolie: bug 252428 as requested
[00:43] <jelmer> lifeless: well, even though something may be planned to land rsn it may take far more than that so I'd rather not rely on anything until it's actually there
[00:43] <lifeless> jelmer: fair enough
[00:47] <jelmer> lifeless: alternatively, do you think it's a sane goal to allow repositories to not provide the inventories and revisions versionedfiles?
[00:48] <jelmer> instead allowing functions that provide the unmarshalled objects to be returned
[00:48] <lifeless> we don't generally want to go up to objects at all
[00:48] <lifeless> e.g. diff shouldn't need a full Inventory; that doesn't scale
[00:48] <lifeless> (for inventories I mean) for revisions we have object methods already
[00:49] <jelmer> sorry, I should've phrased that differently
[00:49] <lifeless> The stated goal of the versionedfiles attributes is that other objects that *understand* a particular serializer can use them to do direct access
[00:49] <lifeless> e.g. stacking
[00:49] <jelmer> I don't mean Inventory objects just python objections in general, e.g. inventory deltas as well
[00:50] <lifeless> so, I think its completely fine to have None for those attributes as long as you have a unique serializer, and your code knows how to do all the operations that in the generic Repository are implemented in terms of those attributes
[00:51] <jelmer> at the moment, that would horribly break stacking though
[00:51] <lifeless> I don't think its desirable, but I will agree that having unoverridablecode require them is a bug
[00:51] <jelmer> that's why I've got them implemented at the moment
[00:51] <lifeless> jelmer: stacking will always depend on them
[00:51] <lifeless> jelmer: at least for the foreseeable future
[00:52] <lifeless> (the 1.6 format stacking logic depends on the same /representation/ to apply deltas across repositories)
[00:52] <lifeless> and these attributes are about providing access to representation
[00:53] <jelmer> that's what my question was though
[00:53] <lifeless> if/when we get a stacking facility that does not depend on representation (which group-compress is shaping up into fwiw) then we can do the (non-trivial) work to make every single method stacking aware
[00:54] <jelmer> do you think it's a sane goal to work on allowing stacking on repositories that don't have the same representation?
[00:54] <lifeless> yes
[00:55] <jelmer> ok, that's what I was hoping to hear :-)
[00:55] <jelmer> I may look into that depending on how hard it is, but I probably won't have enough time
[00:55] <lifeless> I suspect its non trivial
[00:56] <jelmer> for now I'll just keep copies of my VirtualVersionedFiles classes in both bzr-git and bzr-svn
[00:56] <lifeless> *every* method that accesses the storage attributes today will need to be taught to stack, and every data-access method needs to fail in such a way that lookups can then be made to the different source
[00:57] <lifeless> it was hard enough doing it on just the 8 or so methods of VersionedFiles
[00:57] <jelmer> lifeless: this would only be for revisions and inventories though
[00:58] <lifeless> k
[01:02] <jelmer> lifeless: "bzr branch" works in bzr-git now (again?) btw
[01:02] <jelmer> I haven't been able to figure out why though
[01:03] <jelmer> it seems just implementing get_revision(), revision_tree() and get_ancestry() on Repository was sufficient
[01:03] <jelmer> which is quite scary, really
[01:03] <poolie> lifeless: would it also work to require the first commit of an inventory in the new repository to require a full text?
[01:03] <poolie> i mean store a full text
[01:05] <lifeless> poolie: pull(other repo) can introduce deltas
[01:05] <lifeless> poolie: so I don't think its sufficient, or necessary
[01:22] <poolie> lifeless: it seems like we need to check the models are compatible every time we add_fallback_repo, do you remember if we do
[01:25] <lifeless> poolie: yes, we do
[01:26] <lifeless>         if not self._add_fallback_repository_check(repository):
[01:26] <lifeless>             raise errors.IncompatibleRepositories(self, repository)
[01:26] <lifeless> which is
[01:26] <lifeless>         return InterRepository._same_model(self, repository)
[01:29] <lifeless> jelmer: I'd really suggest a plugin for the common code rather than having duplication; one extra branch command for early adopters really shouldn't be a show stopper IMNSHO
[01:30] <lifeless> jelmer: but up to you
[01:30] <jelmer> lifeless: I'm getting enough bug reports from people not using the right combination of (bzr, bzr-svn, svn) as it is, would rather not make that a 4-tuple
[01:31] <jelmer> lifeless: also, not looking forward to finding a sponsor for yet another debian package
[01:32] <lifeless> jelmer: well, you could always roll the code into either bzr or each plugin at release time; but like I say, its your call
[01:33] <jelmer> lifeless: sounds like more overhead for myself than copying two files over each time I change them
[01:33] <jelmer> of course, I could always make bzr-git depend on bzr-svn.... :-P
[01:34] <jelmer> lifeless: any reason why having two copies is a particularly bad idea, other than the fact that code duplication in general is bad?
[01:36] <lifeless> jelmer: because it makes testing the impact of a change harder for you
[01:38] <jelmer> poolie: did you see bug 251871?
[01:43] <lifeless> bye bye firefox, OOM killed
[01:53] <Odd_Bloke> bOOM headshot.
[02:07] <lifeless> Odd_Bloke: :)
[02:11] <lifeless> jelmer: can you make 'bzr branch lp:bzr-svn' DTRT - that is download the current development bzr-svn suitable for use with bzr.dev ?
[02:14] <jelmer> lifeless: that should already be the case
[02:14] <lifeless> jelmer: cool
[02:18] <poolie> jelmer: not yet, looking
[02:22] <jelmer> lifeless, did you intend to close the bzr-svn task of bug 252259 as invalid as well?
[02:23] <lifeless> jelmer: no, that was my comment 'lets see if launchpad knows what I mean' :)
[02:26] <lifeless> jelmer: what did my email do to the bug precisely?
[02:27] <jelmer> lifeless: it marked the bzr-search task as invalid and opened a task for bzr-svn
[02:27] <jelmer> then the next email seemed to mark the bzr-search task as invalid again
[02:27] <lifeless> did it mark the bzr-svn task as invalid too ?
[02:27] <lifeless> (the next mail ? )
[02:27] <jelmer> no, that's New atm
[02:27] <jelmer> no, that just marked the bzr-search task as invalid *again*
[02:28] <lifeless> so I sent one email; and  I wanted it to make the bzr-svn bug invalid and the bzr-svn one new
[02:28] <lifeless> oh
[02:28] <lifeless> I sent two emails
[02:28] <jelmer> lifeless: You may want to rephrase that :-)
[02:28] <lifeless> EContext
[02:29] <jelmer> marking the bzr-svn bit as both invalid and new doesn't make sense
[02:29] <lifeless> righto, I think its probably some nasty import error somewhere
[02:29] <lifeless> the SystemError smells of svn bindings or something to me
[02:29] <lifeless> but yeah, I would have like to close the bzr svn bit too
[02:29] <lifeless> done by hand
[02:49] <awmcclain> Sorry for the off-topic question, but which channel would I go to with PPA problems? ubuntu-motu?
[02:51] <jelmer> launchpad I think
[02:54] <lifeless> #launchpad for PPA specific issues (timeouts, crashes in the facility etc)
[02:55] <lifeless> #ubuntu-motu if you just want a hand driving PPA's as they have most of the mentors etc
[02:55] <awmcclain> Gotcha.
[04:21] <alecwh> ﻿Where can I read about sending bzr patches over email?
[04:22] <RAOF> bzr help send?
[04:22] <mlh> er
[04:22] <RAOF> Too slow, apparently.
[04:23] <mlh> yeah, lift your game :-)
[04:23] <alecwh> ﻿Where can I read about sending bzr patches over email?
[04:23] <mlh> ooh here he is again :-)
[04:23] <mlh> bzr help send
[04:24] <alecwh> sorry, I accidentally quit. =\
[04:24] <mlh> happens to the best of us old chap
[04:24] <spiv> alecwh: also, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#sending-changes
[06:27]  * mwhudson pushes the new loggerhead theme to trunk!!!
[06:29] <lifeless> mwhudson: congrats
[06:29] <lifeless> beuno: you too
[06:40] <poolie> woo
[06:40] <poolie> well done
[07:00] <Peng_> Yay. :)
[07:15] <spiv> http://www.toolness.com/wp/?p=71 is interesting.  I guess these people would really like bzr's checkout workflow?
[07:21] <mwhudson> spiv: i wondered whether that was 'ooh, don't really like hg' or 'oooh, don't really get dvcs'
[07:22] <mwhudson> (sprinting so didn't really have enough spare brain cells to actually read the blog post properly)
[07:29] <spiv> mwhudson: it's hard to tell from this distance, really.  Especially if the only dvcs they've used is hg...
[07:57] <poolie> spiv/lifeless: i want to give better messages when repositories are not compatible
[07:57] <poolie> for stacking or other reasons
[07:57] <poolie> at the moment you just get told they're not and that's it, so not much help to a user
[07:57] <poolie> i'm planning to add an alternative api to InterRepository.is_compatible which raises an exception (rather than returning False) if they're not
[07:57] <poolie> so we get to keep that information
[07:57] <poolie> any comments?
[07:58]  * bob2 gives polite 'yay'
[08:00] <spiv> poolie: I like the sound of that.
[08:03] <poolie> eg https://bugs.edge.launchpad.net/bzr/+bug/206258
[08:04] <lifeless> poolie: is_compatible is used for selecting an optimiser
[08:05] <lifeless> poolie: so having one that raises an exception doesn't feel right to me, I can just see use spewing out 10 different incompatibilities
[08:05] <lifeless> s/use/us/
[08:06] <poolie> if you're searching for one where it passes you would not print them
[08:06] <poolie> and we can keep a method that just says 'did it pass'
[08:06] <lifeless> I'm talking the failure mode
[08:06] <poolie> essentially we have at the moment
[08:06] <poolie> if not foo(): raise Exception(generic)
[08:07] <poolie> and i want to invert that
[08:07] <poolie> hm unless there is one method for matching and another for checking?
[08:07] <lifeless> there are N optimisers
[08:07] <lifeless> when none match that will give you N exceptions
[08:07] <lifeless> which one will you show?
[08:08] <lifeless> I think what you want to achieve is good; I'm all in favour of clearer error messages
[08:08] <lifeless> Jelmer has a patch that improves the KnitRepository __str__ to make the rich-roots->plain case more understandable
[08:08] <poolie> hm
[08:09] <poolie> at the moment i actually want to change _same_model, which while it lives in InterRepository is apparently not multiply-dispatched
[08:09] <poolie> being a static method on the base class
[08:09] <lifeless> but a different model doesn't imply an error message
[08:09] <lifeless> its a very specific combination of models that generates an error
[08:09] <spiv> Do we need "incompatible_model"?
[08:10] <lifeless> *everything* is compatible except for "rich-root or subtrees to plain"
[08:11] <poolie> i don't think that's actually true
[08:11] <poolie> there are more implementations of it that check requirements with weaves and knits
[08:12] <lifeless> oh?
[08:12] <poolie> to answer your earlier question if we are searching for a match and none of them matches
[08:12] <poolie> no, i don't think it would be useful by default to tell the user of every possible thing we tried and why it failed
[08:12] <poolie> but i can believe having that information available for debugging might be useful
[08:12] <poolie> into the log or something
[08:12] <lifeless> via a -D flag perhaps
[08:13] <poolie> right
[08:13] <lifeless> quite seriously though, I don't believe there are any other cases where is_compatible falls all the way back to the default implementation
[08:14] <lifeless> there are various InterFORMAT ones
[08:14] <lifeless> there is InterSameData
[08:14] <lifeless> and InterModel1and2
[08:14] <poolie> ok
[08:14] <poolie> i'm going to poke at it a bit more
[08:14] <lifeless> so the only case I know of is Model2and1 that will fail
[08:15] <lifeless> *other* fetch failures can occur
[08:15] <lifeless> but they occur once a selection has been made
[09:21] <philn> jelmer: ping
[10:06] <Jc2k> lifeless: sorry i have no idea
[10:06] <Jc2k> the initial import of all of GNOME ran over a few days, with me stopping and starting as i hit bzr-svn leaks
[10:06] <Jc2k> and the initial import of SVN was only of trunk, i then used svn-import to "top up" and pull the 2000 branches over
[11:41] <james_w> http://www.toolness.com/wp/?p=71
[11:42] <james_w> I'm not posting that as "Bazaar is better than Mercurial", it's s/Mercurial/Bazaar/ as you read and get an idea of how some people dislike DVCS.
[12:02] <spiv> james_w: yeah, I saw that
[12:02] <spiv> james_w: although I think bzr's checkout workflow would answer a bunch of the concerns tehre
[12:03] <james_w> it's odd that he seems to consider a clean merge more dangerous than a clean update
[12:03] <spiv> james_w: there's room for argument, but it's certainly possible to read the core problem as "I don't want the overhead of tracking/merging lots of branches, but the tool doesn't give me any options other than to make branches"
[12:04] <james_w> that's true
[12:14] <luks> I think it's more about that svn allows you to do 'implicit' update
[12:14] <luks> that is, you can commit even if your tree is out of date
[14:12] <keithy> hi
[14:13] <keithy> how do I tell bzr that the current versions I have are the latest, it seems to think that there are conflicts.
[14:15] <james_w> hi keithy
[14:16] <james_w> I'm not sure what you mean, could you expand on your question please?
[14:19] <keithy> I found it bzr resolve --all
[14:34] <TuniX12> hello
[14:36] <TuniX12> when making a change in a file got by bzr how to upload only that change?
[14:36] <james_w> hi TuniX12
[14:36] <james_w> what do you mean by upload?
[14:37] <TuniX12> upload that change to bzr branch
[14:37] <james_w> "bzr push" to an existing branch will push only the difference between that branch and yours, if that's what you mean.
[14:37] <TuniX12> ah thank i thought it push all files
[14:38] <james_w> no, it won't, but it will push a bit more than just the diff to the changed file, as it will have to push the revision information as well.
[14:38] <TuniX12> and sorry for my bad english :p
[14:38] <james_w> no problem :-)
[14:41] <davi_> hi, I'm testing 1.6beta3 and I get a error when trying to create a new copy of a branch. The error is AttributeError: 'property' object has no attribute 'initialize' in bzrdir.py, line 1384. Has anyone seen this? is there a fix?
[14:42] <TuniX12> i get this error bzr: ERROR: Cannot lock LockDir
[14:42] <TuniX12> Transport operation not possible: http does not support mkdir()
[14:42] <TuniX12> any solution?
[14:44] <davi_> ah, found bug report.
[14:44] <davi_> would be nice to have a beta4
[14:46] <TuniX12> ping
[14:53] <luks> these people don't have any patience nowodays...
[16:11] <beuno> yay!  new theme landed!
[17:15] <strk> [24601] 2008-07-28 17:56:28.680 INFO: Committing to: sftp:/.....
[17:15] <strk> Mon Jul 28 18:14:50 CEST 2008
[17:15] <strk> [[17:15] <strk> 18 minutes and counting, for a few lines of commit
[17:15] <strk> Bazaar (bzr) 1.5
[17:16] <beuno> strk, can you take a look in ~/.bzr.log ?
[17:16] <strk> low bandwidth, all used -- still, is a developer really supposed to suffer this much ? or is it a bad bug ?
[17:16] <beuno> there should be something in it
[17:16] <strk> lots of 601.406  SFTP.readv() 13 offsets => 1 coalesced => 1 requests
[17:17] <strk> 497.074  Auto-packing repository <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x87a8c6c>, which has 17 pack files, containing 10300 revisions into 4 packs.
[17:17] <strk> ^^ you're interested in this one most likely
[17:17] <strk> or :
[17:17] <strk> 128.259  Using fetch logic to copy between KnitPackRepository('file:///home/strk/src/gnash/bzr-local-repository/.bzr/repository/')(<RepositoryFormatKnitPack1>) and KnitPackRepository('sftp://strk@bzr.savannah.gnu.org/srv/bzr/gnash/.bzr/repository/')(<RepositoryFormatKnitPack1>)
[17:17] <beuno> strk, right, it's autopacking
[17:17] <beuno> it happens every now and then to make things faster
[17:17] <strk> it's always autopacking
[17:17] <strk> is there a way to make it happen NEVER ?
[17:17] <beuno> strk, no, it should only happen once every N commits
[17:17] <james_w> not currently.
[17:18] <Peng_> That would be bad for performance.
[17:18] <beuno> there is a bug open so that bzr will tell you that it's doing that
[17:18] <strk> well, until I'm back on a good connection and ready to wait x*10 minutes
[17:18] <strk> performance of what ?
[17:18] <strk> it's 24 minutes I'm starving on a commit !!
[17:18] <james_w> hopefully we'll have server-side packing soon, which should be much much quicker.
[17:18] <Peng_> james_w: That won't help sftp.
[17:18] <beuno> james_w, although server-side packing probably won't work with sftp
[17:18] <beuno> :)
[17:19] <strk> what happens if I comment out the line where N commits is checked ?
[17:19] <strk> I mean, what happens if autopack is NOT done ? where's the performance hit going to be noticed ?
[17:19] <strk> or, when
[17:19] <james_w> strk: without packing performance will degrade over time.
[17:20] <strk> by performance you mean time a commit takes to complete ?
[17:20] <Peng_> Performance in general.
[17:20] <Peng_> That would include committing.
[17:20] <james_w> some things will scale with the number of packs, without packing this is the same as scaling with the number of commits, with packing it scales log(number of commits)
[17:20] <strk> can it be worst than it is now ? 30 25 minutes ?
[17:21] <strk> I'm used to a *few* seconds for similar commits with CVS
[17:21] <james_w> yeah, it would include committing. Basically anything that needs to access information in the repository.
[17:21] <strk> it's a very small patch
[17:21] <strk> and I can thinkg of a few lines of log
[17:21] <strk> what else am I missing that needs to generate so much traffic ?
[17:22] <james_w> it is packing locally, which means that it is pulling down all of the repository data and pushing it back up organised slightly differently I believe.
[17:22] <strk> argh
[17:22] <strk> crazy
[17:23] <beuno> strk, yes, it is. It will be fixed
[17:23] <strk> would a lightweight checkout avoid all of this ?
[17:23] <james_w> no, I don't think so.
[17:23] <strk> damnit, it's depressing
[17:24] <strk> maybe we should setup a cvs commit-hook doing the bzr commit remotely
[17:24] <beuno> james_w, I think he should be able to run a cron that packs?
[17:24] <beuno> that may mitigate it a little bit
[17:24] <strk> done
[17:25] <strk> 30 minutes
[17:25] <strk> I'm on low bandwidth
[17:25] <james_w> yeah, that should help. I assume that the autopack logic looks at the number of packs as well as the number of commits.
[17:25] <strk> can't do "offline-commit" forever
[17:25] <strk> hard to collaburate with others if I keep all the commits locally
[17:25] <strk> was used to do very frequent small commits
[17:25] <beuno> strk, you could run a cron to execute "bzr pack" on the branches every... week?
[17:25] <strk> beuno: would it need bandwidth ?
[17:26] <beuno> that will probably avoid hitting autopacking remotely most of the time
[17:26] <beuno> strk, not of the cron runs on the server, no
[17:26] <strk> oh
[17:26] <strk> that'd be savannah
[17:27] <strk> well, I've been online way too much now. lifeless: I hope you can take care of this with savannah hackers.
[17:27] <strk> thanks for your patience
[18:30] <jam> as an aside, if you ^C during the autopack, the commit still was pushed
[18:31] <jam> so it still counts as valid
[18:31] <jam> though it isn't something I would generally recommend.
[19:02] <james_w> I've got a test problem where calling branch.bzrdir.open_workingtree() seems to either give a different tree to the one that I expect, or doesn't have the changes that were made in the test code.
[19:02] <james_w> I think it is the latter, as the path in the repr is correct.
[19:03] <james_w> so I create a tree, make a couple of commits, and then make a call that eventually ends up the code I am testing. That code receives a branch, and I need a wt, so I try and open it, and the tree I am given has no revision history.
[19:04] <james_w> does this indicate a problem, and that I need to modify the code to provide a working tree directly, as I can never be sure that re-opening the working tree will do the right thing?
[19:31] <jam> james_w: well, re-opening the WT should give the right answer, unless you are using a MemoryTree
[19:31] <jam> also, are you sure you are changing the right paths?
[19:31] <jam> Often, you might have created the branch/tree in a subdir
[19:31] <jam> but then possibly modified the files in the current dir
[20:07] <Roumanos> hello,
[20:07] <Roumanos> if it some is available, i have a question :
[20:08] <Roumanos> it's possible to push on a server my modified file ( not the revision file .bzr )
[20:08] <Roumanos> The commande bzr export work but only on local ( sftp not work with export ...)
[20:08] <Roumanos> Thx
[20:08] <beuno> Roumanos, you mean the files, but not the revision data?   You can use bzr-upload, which will just upload the working tree
[20:09] <Roumanos> yes
[20:10] <beuno> Roumanos, https://launchpad.net/bzr-upload
[20:10] <Roumanos> Perfect !
[20:10] <Roumanos> very thx !!!!
[20:11] <Roumanos> exactly what i research !
[20:11] <beuno> Roumanos, your welcome
[20:22] <Roumanos> the download page is empty, not yet available ?
[20:22] <Roumanos> need to get this by bzr ? :P
[20:22] <beuno> Roumanos, not as a release. Are you on Ubuntu?
[20:22] <beuno> yes, you get this through bzr  :)
[20:23] <beuno> mkdir ~/.bazaar/plugins && bzr co lp:bzr-upload ~/.bazaar/plugins/upload
[20:23] <beuno> and you're set
[20:23] <Roumanos> no sorry, gentoo ....
[20:24] <beuno> that should work on Gentoo just as well
[20:24] <Roumanos> yes, just need to dl this plugin ....
[20:25] <beuno> Roumanos, the command above will work in Gentoo
[20:26] <Roumanos> Yes, it's working great !
[20:26] <Roumanos> big thanks for this very quick reponse !
[20:26] <beuno> Roumanos, it's what we do (tm)
[20:27] <beuno> feel free to file bugs if you need any additional features
[20:27] <Roumanos> ;-)
[20:27] <Roumanos> ok, i will look on this plug-in and make a summary later !
[20:27] <Roumanos> thansks
[20:33] <aquarius> I'm sure this gets asked a lot (so do please point me at URLs), but what would be the benefits of using bzr rather than svn for keeping my home folder in a VCS? One .bzr folder (rather than one per folder) is good; are there other benefits I don't know about?
[20:35] <luks> keeping your home folder in a VCS is a bad idea, no matter what VCS you use
[20:36] <aquarius> luks: really? I'm forever losing things, and having numerous different machines and having to repeat the same configuration changes and installations on all of them is jolly awkward.
[20:37] <luks> what kind of things are you losing?
[20:37] <luks> versioning config files is fine, versioning your whole ~ is not (IMO)
[20:39] <aquarius> random files that I accidentally delete, or that I create on one machine and then don't have on others.
[20:39] <aquarius> I'm not going to drop my music collection into svn :)
[20:41] <luks> if you can accidentally delete a file, I don't think you will always add and commit those random files to a VCS
[20:41] <aquarius> no, I agree. I'll still miss some. Not all, though.
[20:42] <luks> I don't know, I really don't like this "versioned file system" idea
[20:43] <luks> or, maybe I'd like it, but not in a VCS intended for source code
[20:44] <luks> but if you decide to go this way, I don't think you would enjoy using bzr for this (too slow for that kind of working tree)
[20:44]  * luks waits for people to disagree
[20:45]  * aquarius nods. That's useful advice, and thanks.
[20:47]  * Jc2k would disagree
[20:47] <Jc2k> we are thinking of using bzr instead of git for our versioned file system
[20:47] <Jc2k> though, to be fair, rewriting the bits of bzr we need in c
[20:57] <luks> I wonder why people in #svn so often mention a non-existing command 'bzr unversion'
[20:57] <fullermd> They're just being subversive.
[21:15] <aquarius> If I've got a bzr copy of a project in Launchpad, and I want to publish the changes I've made so the project team can look at those changes, am I supposed to publish them to my +junk folder on LP or to the project itself in a branch named by me? Bit confused...
[21:16] <james_w> Odd_Bloke: congratulations. Isn't that your first package in Debian?
[21:16] <LarstiQ> aquarius: ~aquarius/project/branch-name
[21:16] <james_w> hey LarstiQ
[21:16] <LarstiQ> hey james
[21:16] <aquarius> LarstiQ: ah, excellent.
[21:26] <aquarius> hrm. Confused, again. I bzr pushed to launchpad (thanks, LarstiQ) and it's created that branch, but it's not clear to me that there's actually code there for people to look at. https://code.launchpad.net/~sil-launchpad/gwibber/system-buttons
[21:27] <beuno> aquarius, http://bazaar.launchpad.net/~sil-launchpad/gwibber/system-buttons/changes
[21:27] <beuno> Launchpad takes a while to scan the commit messages
[21:28] <beuno> but your branch is there
[21:28] <aquarius> wow! did I miss a link to that page or is it just not there yet?
[21:29] <beuno> aquarius, it's not there yet, I cheated. It should be on there soon-ish, and there is a bug open to show that link right away
[21:29]  * aquarius grins
[21:29] <aquarius> so I was right to be confused :) Your bug: good work there :)
[21:29] <beuno> aquarius, :)
[22:22] <abentley> lifeless: ping
[22:34] <jam> aquarius: at the bottom of https://code.launchpad.net/~sil-launchpad/gwibber/system-buttons
[22:34] <jam> it does say "This branch has not been scanned yet"
[22:34] <jam> though I won't say it is very obvious
[22:40] <thumper> aquarius: there is a LP rollout shortly that should fix the scanner problem
[22:41] <aquarius> jam, thumper: yeah. I didn't know what "scanned" meant -- it seems to mean "no-one can get at this branch yet", which I don't mind, but having a thing which says "this can take a few hours" might not hurt. (Or, just fix the problem by making scanning happen straight away, if that's possible.)
[22:42] <jam> well, it is supposed to only take 5 min or so
[22:42] <jam> I don't know what the hold up is
[22:42] <thumper> jam: the hold up is a bug which causes a mysql branch to fail after 12 minutes
[22:42] <thumper> jam: which it tries every time
[22:44] <jam> thumper: so it is a 12-min timeout, then it gets another branch scanned, repeat ?
[22:45] <thumper> jam: so it gets everything to scan (which may include multiple mysql branches), then does them one after the other
[22:45] <thumper> jam: any that fail, get tried the next time around (1m cron)
[22:46] <thumper> aquarius: scanning takes bzr metadata and stores it in a database
[22:46] <thumper> aquarius: until the branch is scanned we don't show stuff as we don't know what to show
[22:47] <aquarius> aha, got it. So the branch might be private in some way or something, so the public can't pull from it until scanning has happened?
[22:52] <thumper> aquarius: it is pullable / branchable, but the webapp doesn't know that
[22:53] <aquarius> oh, cool. So people who already know their way around LP will be able to get it, at least?
[22:55] <thumper> aquarius: yes
[23:06] <ryanakca> Could someone help me figure out why I can't bzr init? http://paste.ubuntu.com/31484/plain/
[23:06] <dvheumen> Can anyone tell me how to convert an existing "shared repository with trees" into a "shared repository"?
[23:07] <jelmer> ryanakca: bug in bzr-svn, which has been fixed in newer versions of bzr-svn
[23:07] <jelmer> ryanakca: as a workaround, try "bzr --no-plugins init"
[23:07] <jelmer> dvheumen: You mean into a shared repository without trees?
[23:08] <dvheumen> jelmer: yes that what I mean... I tried out 'bzr reconfigure' but I don't know how to change it to treeless
[23:08] <ryanakca> jelmer: splendid, thanks :)
[23:11] <james_w> dvheumen: would you file a bug about that, I think it should know
[23:11] <dvheumen> james_w: do you mean as a feature request?
[23:12] <james_w> yes please
[23:12] <dvheumen> k, I'll do that, tnx
[23:12] <james_w> dvheumen: and to do it now you can use "touch .bzr/repository/no-working-trees"
[23:12] <james_w> "bzr remove-tree" will remove any existing working trees that you don't want.
[23:13] <dvheumen> james_w: I already found out about that command, that wasn't the problem... it's just that new branches would still have trees
[23:14] <dvheumen> james_w: should I report the bug as a missing feature for 'bzr reconfigure'?
[23:15] <dvheumen> or should I just say 'Can't convert repository to treeless repository' (in a few more words)
[23:15] <james_w> yes please, I've been looking for somewhere to put that function and reconfigure seems like the best place
[23:15] <james_w> well, if you just report the latter I'll follow up and recommend the former.
[23:17] <ryanakca> jelmer: untill I get to upgrade, any other workarounds? "bzr --no-plugins init" gives ``bzr: ERROR: No repository present: "file:///home/ryan/work/kubuntu-startpage-mockup/"''
[23:18] <jelmer> ryanakca: Is there perhaps a .bzr directory in that location already?
[23:18] <dvheumen> james_w: Isn't this bug report about the same issue? https://bugs.launchpad.net/bzr/+bug/145033
[23:18] <ryanakca> jelmer: oops, thanks
[23:19] <dvheumen> okay, so on second thought I won't report :P
[23:19] <dvheumen> btw, could you explain what 'triaged' means exactly? ('cause I've only got a faint clue at the moment)
[23:21] <james_w> dvheumen: hey, yes it is, thanks.
[23:22] <james_w> triaged is supposed to mean "enough information that a developer can start work on it"
[23:24] <dvheumen> ah right, okay, tnx guys :D