[00:00] <igc> poolie: ok. I actually think it's pretty straight forward to add deep history support to usertest so I'll do that today after kicking off a conversion
[00:00] <lifeless> poolie: I think its interesting to have deep linear too; because many conversions will be like that
[00:01] <poolie> sure
[00:01] <lifeless> and in the short term, most huge histories will be conversions
[00:01] <foom> yes, my repo came from svn, so it's essentially linear
[00:10] <poolie> i guess for ease of understanding the results we need to pick one main case to graph
[00:11] <lifeless> I would say rather that we should be repeating on the same graph
[00:11] <lifeless> we might have N big graphs to test, all different
[00:11] <poolie> testing N could be good, i'm just a bit concerned that if we produce too much output data it will not be read
[00:12] <lifeless> well whats the audience
[00:12] <lifeless> will the audience read 1, or N, or none ?
[00:14] <lifeless> right now I don't look at usertest daily
[00:15] <lifeless> I only look at such things when I'm a) deciding what to put in my pipe, and b) evaluating how I'm doing with my current changes
[00:16] <lifeless> if you have someone who is trying to do a) on any of a number of scales, N graphs is little harder to read that 1, and better at detect regressions caused while operating on code for the case of b)
[00:16] <lifeless> I'll wager that you have a similar use pattern
[00:17] <lifeless> but that Ian, who is focusing on a) in a broad sense, daily, looks at it quite frequently.
[00:28] <lifeless> http://www.smh.com.au/articles/2008/02/05/1202090393959.html <- hmm
[00:29] <poolie> i'm fixing a merge conflict to merge, and jam has a todo asking for the trace file to be line buffered so you can more easily read it
[00:29] <poolie> should i do a trivial change to have a debug option to turn that on, or yagni?
[00:30] <lifeless> the trace file is buffered right now right?
[00:30] <lifeless> for performance
[00:30] <poolie> yes
[00:30] <poolie> up to several kb, whatever is the python default
[00:30] <lifeless> I've had no trouble tailing it
[00:31] <lifeless> but if we change it yes, it should be a flag
[00:32] <poolie> oh, actually the comment is wrong, it is always line buffered
[00:32] <poolie> which is fine
[00:32] <poolie> thanks Teddy! :)
[00:32] <lifeless> lol
[00:35] <mattimustang> hi, i'm looking at converting from svn to bzr. Does bzr support svn style properties?
[00:35] <lifeless> mattimustang: I answered your question before; did you not see the answers ?
[00:35] <mattimustang> sorry i missed it and lost it in scollback :(
[00:36] <mattimustang> so it doesn't support arbitrary properties like svn?
[00:36] <lifeless> 10:39 < lifeless> some yes
[00:36] <lifeless> 10:40 < lifeless> is this for 3rd party extension, or for file-ending support on windows etc?
[00:36] <lifeless> 10:40 < lifeless> (that is are you asking about 'generic stuff' or specific features)
[00:36] <lifeless> 10:41 < foom> it doesn't support keywords or eol-style
[00:36] <lifeless> 10:41 < lifeless> foom: yet; I have a plan.
[00:36] <mattimustang> thx
[00:37] <mattimustang> I have custom properties aside from what svn uses (keywords eol-style etc)
[00:37] <lifeless> per file or per commit ?
[00:37] <mattimustang> per file
[00:37] <mattimustang> file metadata like unix permissions, owner, group
[00:38] <lifeless> ok
[00:38] <lifeless> well I'm designing a plugin to store those precise attributes
[00:38] <lifeless> with a lookaside structure from the core
[00:39]  * jelmer wakes up
[00:39] <lifeless> we have arbitrary revision properties, and you can do things like e.g. storing a dict of the changed file properties you want in a revision property - so {fileid:newvalue, ...}
[00:40] <lifeless> this isn't entirely ideal, but making arbitrary properties DTRT all the time is rather tricky, when you have to consider performance-at-alarge
[00:40] <mattimustang> i really need the metadata to stay with the file it belongs to
[00:40] <lifeless> yes, what I describe does that
[00:40] <lifeless> files have uuid
[00:40] <mattimustang> if files move I don't want to have to update some other manifest elsewhere
[00:40] <lifeless> a rename does not change the uuid (which we call file_id)
[00:42] <jelmer> lifeless: wouldn't it make more sense to store it in a . file in the root of the tree?
[00:43] <lifeless> jelmer: that makes it a user file
[00:43] <jelmer> I wouldn't want to check out a 30000-revision branch with several thousand files that each have a couple of properties set
[00:43] <lifeless> jelmer: remember the trouble with altering the representation of .bzrignore
[00:43] <foom> so store it in a \0 file in the root of the tree? :)
[00:44] <lifeless> a) we reject that filename, b) its the same problem
[00:44] <jelmer> lifeless: .bzr/repository/fileprops.knit would be ok as well
[00:45] <lifeless> jelmer: a knit? wtf
[00:45] <jelmer> that's also how i'd like to see .bzrignore support
[00:45] <jelmer> ed
[00:45] <jelmer> well, a knit or a pack or whatever
[00:45] <jelmer> it can be in the pack file as well, depending on your repository type
[00:45] <lifeless> jelmer: in the broad sense you are saying 'this should be in the core'
[00:45] <jelmer> lifeless: Yes, I am.
[00:46] <lifeless> jelmer: and thats fine, I want to get something up and working as a plugin, then when its stable, design an appropriate extension to core to do it well.
[00:46] <jelmer> lifeless: ah, ok. I hadn't seen you say that anywhere yet. That makes sense though.
[00:46] <lifeless> as a plugin the goal is to work and be decoupled from repository format
[00:47] <lifeless> figure out all the data needed, how it changes, what it needs. then design good storage.
[00:47] <lifeless> so I'm thinking it will be slowish as a plugin, but easy to tweak
[00:48] <jelmer> I would really like to avoid a "bzr setprop" kind of UI for setting these things btw
[00:48] <lifeless> oh I cannot tolerate that ui
[00:48] <lifeless> never happen
[00:49] <jelmer> ok :-)
[00:49] <lifeless> I mean, see my comments re the shell hook stuff
[00:49] <mattimustang> what would propose then?
[00:50] <jelmer> lifeless: I think being able to write python should not be a requirement for being able to write bzr hooks.
[00:50] <lifeless> mattimustang: well I made a suggestion, or do you mean about how to activate this feature for a branch ?
[00:51] <lifeless> jelmer: I think our hooks and hg/svn hooks are different beasts.
[00:51] <jelmer> lifeless: For commonly used hooks, those should definitely be in python.
[00:51] <lifeless> jelmer: our hooks are gateways into the core library; like svn's baton passing.
[00:51] <mattimustang> well my original question was does bzr support it and it seems that it doesn't
[00:51] <lifeless> the stuff you want should be done by specific adapters
[00:51] <jelmer> s/commonly/installable/
[00:51] <lifeless> mattimustang: it has arbitrary properties that can be set per commit; you can build out what you want easily there
[00:52] <mattimustang> how would you do that per file then?
[00:52] <jelmer> lifeless: For example, we check whether a commit message contains a specific line here at a svn repository
[00:52] <lifeless> mattimustang: I already described it; you seem to think it wouldn't work.
[00:53] <jelmer> lifeless: most people know shell and can write a two-line shell script that checks a commit message is valid.
[00:53] <lifeless> jelmer: thats fine; do an adapter like I posted to the list for running make check. Then most users can write such a two line shell script
[00:53] <lifeless> jelmer: this is entirely different from trying to write a FFI to shell for our hooks.
[00:54] <mattimustang> so that is still using svn main repo for checkins and hook script. ok that is fine i can understand that approach but what about going purely bzr?
[00:54] <lifeless> mattimustang: huh? what I described was using bzr
[00:54] <foom> my 2 line shell script for doing that exact function is actually a 116 line python script. :)
[00:54] <jelmer> lifeless: Which thread was this? I don't think I've seen that.
[00:56] <foom> 43 lines of which are a function called "get_cmd_output" which I use to call "svnlook log" and "svnlook changed", since the server doesn't have python 2.4 (and thus the subprocess module), and popen.* are terrible
[00:56] <jelmer> you mention posting a pre-commit-check hook in the "Enhancing hooks" thread, but I can't find it
[00:56] <lifeless> jelmer: 1202182868.659.144
[00:56] <lifeless> Config.get_user_section api
[00:57] <mattimustang> "(11:39:13 AM) lifeless: we have arbitrary revision properties, and you can do things like e.g. storing a dict of the changed file properties you want in a revision property - so {fileid:newvalue, ...}" is that what you are talking about?
[00:57] <lifeless> mattimustang: yes
[00:57] <mattimustang> ok
[00:58] <jelmer> lifeless: I don't see how that is all that different from my shell hooks plugin
[00:58] <jam> poolie: I did intend to have bzr-log-rss as part of the bzr project. I just wanted to allow someone else to have access aswell. I did the same thing for bzr-pqm-devel since James didn't want to be in ~bzr
[00:58] <poolie> got it
[00:59] <lifeless> jelmer: I didn't claim it was.
[00:59] <lifeless> jelmer: Ian posted work to create a generic FFI for our python hooks.
[00:59] <lifeless> jelmer: I think that that is a bad idea.
[01:00] <jelmer> lifeless: ahhh, ok. I see your point.
[01:01] <lifeless> in short - some hooks that work well available for shell - great.
[01:01] <lifeless> all hooks in shell - are you insane?
[01:03] <jamesh> you think multiple fork+exec's for common operations would be a performance problem?
[01:03]  * fullermd is insane.
[01:03] <lifeless> jamesh: we'll only pay that when someone has chosen to use a shell hook
[01:03] <jelmer> lifeless: right, and there's not always an obvious conversion between python types and shell types..
[01:04] <lifeless> jamesh: so no, because we can and should also make it really easy to write absolutely trivial python hooks - by providing base class hook implementations that do most of the grunt work
[01:04] <jamesh> lifeless: one thing that would be nice would be to centralise the hook registration APIs
[01:04] <jamesh> lifeless: rather than doing some on SmartTCPServer.hooks, some on Branch.hooks, etc
[01:04] <jelmer> jamesh: even when done centrally, those hooks would still only apply to some objects
[01:05] <lifeless> jamesh: like the two like 'check a regex in the commit message' should be in python, about 8 lines - import regex, import a currier that takes a plugin name and looks for config stuff with that prepended, and then a simple 'get regex, execute it, return'
[01:05] <jamesh> jelmer: I realise that.
[01:05] <lifeless> jamesh: I don't actually like a single global registry; what is better about it ?
[01:06] <jamesh> lifeless: well, the current system kind of works against lazy_import
[01:07] <jamesh> lifeless: if I want my plugin to hook the SmartTCPServer, then every invocation of bzr is going to import bzrlib.smart.server once my plugin is installed
[01:07] <lifeless> OTOH we wouldn't need lazy_import if python imports didn't suck so much
[01:07] <lifeless> so I have on my todo list to fix that for bzr
[01:07] <lifeless> and a pretty good idea about how
[01:08] <lifeless> what else?
[01:08] <foom> there's already packages which implement lazy module importing
[01:08] <jamesh> lifeless: I guess that's my main complaint.  A central hooks registry was a solution to that, but you've obviously thought of some alternatives that might be better
[01:09] <yacc> pkg_resources entry points?
[01:09] <jamesh> lifeless: actually, the other one is discoverability of hooks
[01:10] <lifeless> jamesh: I'd like bzr help plugins/hooks to dump them all
[01:10] <jamesh> okay
[01:10] <lifeless> jamesh: I think thats thats nicer because it allows plugins to add hooks themselves too
[01:11] <lifeless> (not that a central place prohibits that, but because it doesn't lend it self to it quite as nicely if you think about it this way)
[01:11] <jamesh> at the moment you have to dig through the code to find out where to register your hook, what the name of the hook is, and what arguments it should expect
[01:11] <lifeless> yes, that sucks
[01:11] <lifeless> also debug.debug_flags has the same problem
[02:39]  * igc food
[04:04]  * spiv -> late lunch
[04:13] <abentley> Can I not join ~bzr-log-rss-devel please?  I get enough spam from Launchpad as is.
[04:15] <abentley> by spam, I mean bugs on bzr-eclipse, bugs on bzr-webserve, branchfeed, etc.
[04:15] <abentley> These are not projects I have ever been interested in.
[04:35] <Aloha> when i "man bzr" i get this weird output http://www.pastebin.ca/893506
[04:35] <beuno> Aloha, that's wierd, me too
[04:36] <beuno> but if I have my terminal maximized, it doesn't happe
[04:36] <beuno> *happen
[04:37] <beuno> Aloha, you should report the bug to the Ubuntu package (might also happen in Debian, dato?)
[04:38] <Aloha> ok
[04:38] <beuno> Aloha, that would be https://bugs.launchpad.net/ubuntu/+source/bzr/
[04:38] <Aloha> beuno, thnx
[04:39] <beuno> I'm going to bed now, I swear  :D   g'night all
[04:39] <beuno> Aloha, thanks for filing it!
[04:39] <mtaylor> abentley: I've got a question about the bundlebuggy workflow... that's the pqm, right? so once a merge is approved there, it gets merged to the tree?
[04:39] <abentley> mtaylor: No, they are separate systems.
[04:40] <mtaylor> ok. so what happens once a merge is approved on bb?
[04:40] <abentley> mtaylor: A person with clearance submits it to PQM.
[04:41] <mtaylor> abentley: so there's still a manual step there then
[04:41] <abentley> mtaylor: Indeed, and frequently more.
[04:41] <abentley> Because many patches need to have conflicts fixed before they can merge cleanly.
[04:41] <mtaylor> ah
[04:41] <mtaylor> ok
[04:42] <mtaylor> and then the PQM system is the one that runs the unit tests before pushing to the tree, no?
[04:42] <Aloha> bug filed
[04:42] <abentley> Yes.  Technically it merges, runs unit tests, then commits.
[04:42] <mtaylor> cool. makes sense
[04:43] <abentley> The conflict issue has gotten a lot better since we started doing NEWS alphabetically, though.
[04:44] <abentley> So submit-from-bb isn't completely out of the question.
[04:44] <mtaylor> I tell you what, changelogs and news files really screw with merges in general :)
[04:44] <abentley> mtaylor: Someone should write a merge algorithm for NEWS and CHANGELOG files.
[04:44] <mtaylor> you could almost have bb submit and then ask for a re-submit if the merge didn't work.
[04:44] <mtaylor> abentley: I totally agree. I'd be in favor of that!
[04:45] <mtaylor> abentley: my debian/changelog files are always a problem
[04:45] <abentley> mtaylor: Great.  Let me know when you have something >;)
[04:45] <mtaylor> :)
[04:45] <mtaylor> so bzr-pqm is just the submit-to-pqm plugin though, right? Is pqm itself released?
[04:45] <abentley> Yes it's an open project.
[04:48] <abentley> http://people.ubuntu.com/~robertc/pqm/
[04:48] <mtaylor> abentley: awesome. thanks
[04:49] <bob2> is there any support for plugging file-type-specific merge algorithms into bzr?
[04:50] <abentley> bob2: No, but you can write your type-specific merge so that it falls back to merge3.
[04:50] <abentley> General merge algorithms are pluggable.
[04:51] <bob2> ah
[04:51] <bob2> neat
[04:52] <mtaylor> abentley: so what if bob2 wrote a file-type merge algorithm, and I wrote a debian/changelog algorithm, and I had both file types in my tree?
[04:52] <abentley> mtaylor: Obviously, it doesn't scale.
[04:52] <mtaylor> :)
[04:53] <abentley> I did some work on per-file merge algorithms, but I didn't nearly finish it.
[04:53] <mtaylor> I'd say I'd think about it further, but I'm like 12 deep on my stack of non-essential work at the moment anyway
[06:07] <spiv> poolie: a fix for bug 185394 is on the list, if you'd like to review it
[06:07] <ubotu> Launchpad bug 185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Critical,Fix committed] https://launchpad.net/bugs/185394
[06:09] <fullermd> Oooh.  Purdy.
[06:32] <poolie> thanks spiv
[10:20] <mazzanet> herro
[10:21] <mazzanet> how do you get a diff of the local tree and the repository that includes any new files added locally?
[10:22] <mtaylor> mazzanet: have you commited those files ?
[10:23] <mazzanet> i don't have commit access to the repository
[10:23] <mazzanet> ie. i'm making a patch
[10:24] <fullermd> diff should do it just fine in general (though it won't for binary files).
[10:24] <bob2> "bzr diff" will show the difference between your current checkout and the main thing
[10:24] <fullermd> The usual answer, though, is jut to commit in a local branch.  Then you can send a merge directive and keep all your metadata.
[10:25] <bob2> but this new-fangled distributed thing means you can create your own branch ;)
[10:25] <mazzanet> bzr diff isn't including the new files
[10:25] <fullermd> Did you 'bzr add' them?
[10:25] <bob2> (bzr add will work even if you can't commit)
[10:25] <mazzanet> really?
[10:25] <mazzanet> crazyness
[10:27] <mazzanet> cheers
[10:27] <mazzanet> *dances*
[10:29] <jblack> bob2???
[10:30] <jblack> Bob2!!!
[10:31] <fullermd> jblack: Oh, hey there.  Didn't see you come in.
[10:31] <jblack> I came in on tippy-toes. ;)
[11:35] <jblack> cprov too! wow
[11:36] <cprov> jblack: hi James. Good to see you again.
[11:36]  * jblack gets amazed by the people he sees when he crawls out from under his rock
[11:36] <jamesh> hi jblack
[11:36] <jblack> Hey jamesh
[11:38] <jamesh> jblack: and bob2 still has the hair ...
[11:38] <jamesh> and denies that he plays goon of fortune
[11:38] <jblack> Heh.
[12:47] <abentley> jblack: Hi.
[12:50] <jblack> Hi
[12:51] <CardinalFang> Aloha.
[12:51] <abentley> What colour rock have you been hiding under?
[12:52] <jblack> A black one, of course
[12:52] <jblack> it sounded funnier in my head.
[12:52] <abentley> Heh.
[13:00] <kiko> heh
[13:01] <kiko> hey jblack how's it going?
[13:29] <jblack> hi
[13:29] <jblack> Pretty good.
[13:31] <ubotu> New bug: #189567 in bzr "output to a terminal should default to using /usr/bin/pager" [Undecided,New] https://launchpad.net/bugs/189567
[15:12] <synic> anyone awake?
[15:12] <synic> how can I get bzr to mark files with the current revision number?
[15:13] <Parker-> hmmhh... like $rev$ or something?
[15:14] <synic> yeah
[15:14] <jam> synic: short answer, no
[15:14] <jam> longer answer... http://bazaar-vcs.org/KeywordExpansion
[15:14] <jam> you might look at "bzr version-info"
[15:14] <synic> k
[15:14] <Parker-> heh
[15:14] <jam> But it is more about putting it into another file
[15:14] <jam> ATM we don't change files for you on commit
[15:15] <synic> alright
[15:15] <Parker-> hmmhh... in future... is it possible to lock files?
[15:16] <Parker-> if branch is checkouted
[15:19] <Parker-> (or binded)
[15:36] <Spads> So I once had infinity rattle off a zillion commands at me explaining how to do this, but short term memory's always the first to go...
[15:37] <Spads> I've got a tree where I maintain an internal patch to upstream sources.  new tarballs appear periodically, and I want to just incorporate that stuff and keep my set of changes on top.
[15:37] <Spads> infinity said there was a "maintaining a patch" section in the docs, but I can't find it
[15:37] <Spads> he mumbled about doing lots of imports from tarballs, but that seems to blat the whole tree out with the upstream files.
[15:39] <Spads> HI!  I always swap "infinity" and lifeless in my head
[15:39] <Spads> hi lifeless
[15:39] <Spads> they're both so eternal
[15:40] <jam> Spads: there is http://bazaar-vcs.org/TrackingUpstream
[15:41] <jam> And I know there is "bzr import" provided by bzrtools
[15:41] <jam> Generally, I would say you want to have a pristine branch of upstream
[15:41] <jam> which your work is derived from in another branch
[15:41] <jam> and then you go to upstream
[15:41] <jam> update to the latest tarball
[15:41] <jam> commit
[15:41] <jam> then go to your branch
[15:41] <jam> merge in the changes
[15:42] <jam> commit
[15:42] <jam> go on with your life
[15:42] <jam> http://jameswestby.net/tips/tips/hacking-a-project-with-bzr.html
[15:42] <jam> also describes that workflow
[15:42] <jam> only with "upstream" being in svn
[15:42] <Spads> okay, this is close to what we were doing already.  I may have misheard him as it sounded like he was talking about everything in-place
[15:42] <jam> Spads: he has a plugin to do that
[15:43] <jam> but I don't think it is fully released yet
[15:43] <Spads> ahaaaa
[15:43] <jam> Last I read was that it needed a bit of polish, and should be released within the next month or so
[16:19] <muszek> hi... I have a local branch binded with a branch on a remote server.  I'm using bzr+ssh URI.  When commiting, I'd like the remote working directory to be updated at the same time... is it possible?  Right now I have to issue commit locally, wait till it's finished and issue "bzr update" command on the remote server (I want to skip that 2nd part)
[16:22] <jelmer> muszek: you can use the push-and-update plugin for that
[16:25] <muszek> jelmer: thanks
[16:48] <muszek> can I specify the path that I want to run bzr commant at?  something like "ls -A /var/www" shows me stuff in a specified directory (not the one I'm currently at).  Say I'd like to run something like "bzr update /var/www/myapp"
[16:50] <jelmer> bzr update /var/www/myapp should work
[16:50] <pygi> muszek, yes, you can ;)
[16:51] <muszek> damn... It does work... I must have messed up something before.  thanks and sorry guys.
[16:51] <Wonko> Hi guys, I have a noob Q: I have a project on two machines that has a settings file that differs for these machines. Everything else is the same and needs to be kept in sync.
[16:51] <pygi> muszek, no worries ;)
[16:51] <pygi> Wonko, you can ignore that settings file
[16:52] <pygi> Wonko, bzr ignore [file]
[16:52] <Wonko> But the settings file might change in the non-specific parts , is there a better way maybe?
[16:52] <Wonko> thought about ignoring, but it seemed unelegant ;)
[16:53] <pygi> Wonko, perhaps you might want to split settings file to two separate files? One common, and one specific?
[16:53] <pygi> Wonko, and just ignore the common one? :)
[16:54] <Wonko> @pygi: that sounds like a good idea. Mercurial has something called "Mercurial Queues" that allow me to "plug in" patches, which would sound ideal for my case. Does bzr have something like that?
[16:55] <Wonko> ( Hg stuff: -> http://hgbook.red-bean.com/hgbookch12.html#x16-26700012 )
[16:55] <pygi> Wonko, gimme a moment to read it pls
[16:55] <Wonko> I'm still thinking about where to move to from CVS, bzr or Hg (or maybe darcs) ..
[16:55] <Wonko> sure, take your time, and THANKS!
[16:59] <pygi> Wonko, per-se, I don't think bzr has something similar, however I believe a plugin like that could be written
[17:00] <Wonko> k, thanks so far!
[17:01] <pygi> Wonko, thank you, and dont hesitate to ask if you have more questions :)
[17:01] <foom> i wish there was a way to have both, at once.
[17:02] <foom> a revision history of the changes i actually made, *and* a sensible split into patches of the same changes
[17:02] <pygi> foom, that approach doesnt scale .... i.e. see darcs :)
[17:02] <foom> pygi: ...just because darcs doesn't scale doesn't mean what i want is impossible. :)
[17:03] <pygi> true that foom :P
[17:03] <pygi> foom, you could write a bzr plugin that does that, anyway
[17:03] <foom> no i couldn't
[17:03] <foom> maybe someone could
[17:03] <pygi> hehe :)
[17:04] <foom> but i don't even have a precise enough idea of what I want it to do to start.
[17:08] <batoms> is there a quick fix for a corrupted dirstate?
[17:08] <batoms> mine appears to be corrupt and i can't do anything on my tree
[17:10] <luks> a quick fix would be "bzr branch <broken> <fixed>"
[17:10] <luks> but filing a bug report about that is probably a good idea, too
[17:10] <pygi> and we'd appreciate it :)
[17:12] <batoms> branching doesn't work
[17:12] <batoms> #186014
[17:12] <batoms> Bug #186014
[17:12] <ubotu> Launchpad bug 186014 in bzr "MemoryError on diff/commit" [Undecided,New] https://launchpad.net/bugs/186014
[17:13] <luks> branch fails with the same error as e.g. diff?
[17:14] <batoms> pretty much everything fails
[17:14] <batoms> except for bzr info
[17:14] <batoms> and bzr log
[17:14] <luks> umm, I'm pretty sure branch used to work
[17:14] <batoms> the last comment on that bug give the traceback
[17:15] <batoms> for branch
[17:16] <luks> hmm
[17:16] <luks> rm -r broken/.bzr/checkout && bzr branch broken fixed
[17:17] <luks> but obviously backup the broken one before
[17:19] <batoms> but then i lose track of the my recent uncommitted changes on the tree
[17:20] <abentley> batoms: after that, you can move the .bzr/checkout from the new tree into the old one.
[17:21] <batoms> that did the trick, thanks
[17:21] <luks> maybe there should some hidden command to regenerate the dirstate from scratch
[17:22] <foom> jelmer: so i ran bzr svn-push, and it's been running for about 20 minutes so far, and I have no idea what it's doing or if it's going to work; is there any way to have it print some debugging info about what it's doing?
[17:22] <jelmer> foom: If you run it with -Dcommit, it should write debug info to .bzr.log
[17:22] <jelmer> sorry, ~/.bzr.log
[17:22] <abentley> luks: The reason why branch breaks here now is that branch uses the local tree if it can to accelerate the process.
[17:23] <abentley> luks: Perhaps we could hang it off 'reconcile'.
[17:59] <muszek> anyone knows some good article with arugments for using version control systems?
[18:11] <abentley> luks, foom: push should work fine with a broken dirstate, so we didn't have to delete .bzr/checkout (though we would have had to replace it).
[18:24] <Parker-> hmmhh... trying to get bzr-svn work... and windows stuff is not aynmore located in http://home.comcast.net/~klight/bzr/
[19:11] <orospakr> What is the proper way to migrate from git to bzr?  The git plugin throws a scary traceback when I try to branch a local git repo.  Tailor adds a gross SHA1 hash to the beginning of the commit messages.
[19:12] <orospakr> ah, bzr-git has a separate branch with pull support.
[19:12] <orospakr> marked "VERY EXPERIMENTAL", though...
[19:13] <luks> should be fine for one-time conversion, I guess
[19:13] <luks> (that is, not incrementally sync the git branch)
[19:15] <luislavena> hello everybody
[19:15] <luislavena> anyone knows why the smart server reports format unnamed when asked for info?
[19:16] <luislavena> bzr info . (pack-0.92)
[19:16] <luislavena> bzr info bzr://localhost => format: unnamed
[19:35] <orospakr> luks, yikes, it won't even load.
[19:35] <orospakr> AttributeError: 'GitRepository' object has no attribute 'base'
[19:36] <beuno> luislavena, you must have a pre 1.0 version of bzr, probably 0.9
[19:36] <beuno> (on the smart server)
[19:36] <beuno> s/0.9/0.90
[19:36] <luislavena> beuno: nop, both 1.1
[19:37] <luislavena> anyway, i'm running on the same machine :P
[19:37] <luislavena> oh, btw, windows... :D
[19:37] <beuno> luislavena, does "bzr version" output the same in both?
[19:38] <beuno> luislavena, oh, and you probably have to provide a full path to the smart server
[19:40] <luislavena> beuno: mmm, I chdir to the path I want to share... and all the other information it returns seems ok...
[19:40] <luislavena> (shared repository, branch info, even the push location)
[19:43] <luislavena> beuno: nop, still the same, even with --directory pointing the same location.
[19:43] <luislavena> weird, but it works.
[20:06] <mtaylor> http://rafb.net/p/0k9wig17.html
[20:06] <mtaylor> um... wtf?
[20:07] <mtaylor> so, he did a bzr merge from a merge directive... then did a bzr revert, then a bzr pull, then a bzr commit
[20:07] <mtaylor> and this is the resulting change
[20:11] <mwhudson> mtaylor: looks like the pull only brought in revision data, not text data
[20:45] <ubotu> New bug: #189709 in bzr "added-but-not-commited files which are removed go into weird limbo" [Undecided,New] https://launchpad.net/bugs/189709
[21:15] <johnny> hi, anybody familiar with the cvsps-import tool?
[21:15] <johnny> i'm not sure if i have enough to make it happen, or i'm missing something
[21:15] <johnny> my cvs fu is weak after years of not using it
[21:36] <lifeless> johnny: sure what problem are you having though ?
[21:36] <johnny> exactly how much access to the cvs tree do i need?
[21:36] <johnny> since it doesn't seem to support :ext: or :pserver:
[21:37] <lifeless> AIUI a copy of it
[21:37] <lifeless> it needs to extract the ,v files
[21:37] <lifeless> because you are converting history
[21:37] <fullermd> I think you can use the non-local protocols if you --use-cvs or something.
[21:37] <johnny> so, not just a checkout ?
[21:38] <fullermd> Probably a lot slower, though.
[21:39] <lifeless> johnny: you can try --use-cvs as fullermd says
[21:39] <lifeless> and no, it does not operate off of a checkout, it operates off of the repo
[21:40] <johnny> syntax ?
[21:43] <lifeless> I've always used it on local paths
[21:44] <johnny> well, i am working with a codecoop repository
[21:44] <johnny> a sf clone kinda thing
[21:44] <johnny> the nightly does seem to have a CVSROOT dir in it
[21:45] <fullermd> Doesn't, you mean?
[21:45] <johnny> it does
[21:45] <lifeless> untar that backup somewhhere then :)
[21:45] <johnny> yeah.. lemme try again
[21:45] <fullermd> Oh.  Yeah, working off that would be a lot quicker than trying to do it remote   :)
[21:45] <johnny> i had problems with it
[21:45] <johnny> we're only talking less than 1000 revs, so either way.. no big deal
[21:45] <johnny> no complicated branching
[21:45] <johnny> etc
[21:46] <johnny> time is not an issue
[21:48] <johnny> here's what i have
[21:48] <johnny> ohnny@beep ~/projects/redemmas $ ls infoshopkeeper-scm-2008-02-06/
[21:48] <johnny> CVS  CVSROOT  infoshopkeeper
[21:49] <johnny> i musta got the command sequence wrong before when trying this
[21:49] <johnny> so this should be enough?
[21:49] <johnny> ohnny@beep ~/projects/redemmas $ bzr cvsps-import infoshopkeeper-scm-2008-02-06/ infoshopkeeper isk
[21:50] <elmo> is there anyway to diff without a working tree?
[21:51] <lifeless> elmo: upgrade your bzr ;)
[21:51] <johnny> lifeless, is that good?
[21:51] <lifeless> johnny: that looks right to me
[21:51] <elmo> lifeless: >> 1.0 ?
[21:51] <lifeless> elmo: 1.1 I think - unless your 1.0 supports --old and --new
[21:51] <elmo> lifeless: mmk
[21:52] <mwhudson> it needs > 1.0
[21:52] <johnny> http://rafb.net/p/yCqF6A35.txt
[21:52] <johnny> that's what i see
[21:57] <lifeless> whats in CVSROOT ?
[21:58] <johnny> CVS dir and a bunch of scripts it seems : commitinfo,checkoutlist,config,cvswrappers,loginfo,modules,rcsinfo , etc
[21:58] <lifeless> ok its legit
[21:58] <lifeless> whats in infoshopkeeper ?
[21:59] <johnny> CVS, and the normal files
[22:00] <lifeless> ,v ?
[22:00] <johnny> ?
[22:00] <lifeless> say you have NEWS
[22:00] <lifeless> is it NEWS
[22:00] <lifeless> or NEWS,v ?
[22:00] <johnny> aha.. just NEWS
[22:01] <lifeless> so ,v is what CVS puts after its database files
[22:01] <johnny> so it's not the full thing then
[22:01] <lifeless> the CVSROOT files - commitinfo etc should also have commitinfo,v for the history of them
[22:01] <lifeless> indeed it does not look like your history
[22:01] <lifeless> there should be some sort of backup tarball you can get
[22:01] <johnny> suprised it even included the CVSROOT then
[22:01] <johnny> i wonder if i can bug them for the whole thing
[22:02] <johnny> it'd prolly be easier to just do it remotely tho
[22:02] <lifeless> jam: ^ can you advise ?
[22:46] <ubotu> New bug: #189757 in bzr "Interrupted initial push leads to branch reference" [Critical,New] https://launchpad.net/bugs/189757
[22:50] <jam> lifeless, johnny: It certainly sounds like you are just getting a checkout, and not the actual repository
[22:51] <jam> It is *close* to supporting :pserver: I just never took the time to actually do it
[22:51] <jam> as most people who are converting have access to their source
[22:51] <jam> and it is faster that way anyway
[22:52] <johnny> well, i guess i could email the codecoop people for the source
[22:52] <johnny> but.. then how can i later sync branches
[22:58] <lifeless> bah
[22:59] <lifeless> soft failures for the lose:
[22:59] <lifeless> Unable to test plugin "launchpad": cannot import name test_lp_registration
[22:59] <jam> johnny: well, you just ask them for another code drop :)
[22:59] <lifeless> our test suite is passing on pqm but the lp plugin tests are not running.
[22:59] <igc> morning
[22:59] <jam> johnny: though if you want ongoing conversions, Launchpad does a pretty good job of it
[22:59] <lifeless> jam: ^ an example of why I don't like the dynamic test stuff you want to do :(
[23:00] <johnny> i'd prefer not to rely on launchpad
[23:00] <johnny> i'd like xmpp notices of commits , and other such things
[23:01] <johnny> and i'd have to wait on them to provide it
[23:01] <johnny> the whole point of this operation is to get a package that is relatively bigger than any of the other code stuff that we have
[23:02] <jam> lifeless: you just make them hard-failures if you have something which looks like "test_*" and doesn't actually load
[23:02] <johnny> so i can test out bzr on it
[23:02] <johnny> to see if it will work for us
[23:02] <jam> johnny: well if that is all you want, the bzr source code is certainly available
[23:02] <jam> if you only have 1k commits, bzr is a lot bigger than that
[23:02] <johnny> i mean with one of our own projects
[23:02] <johnny> to test working with it in real life, with real commits :)
[23:03] <jam> johnny: true, all of the bzr commits are faked :)
[23:03] <jam> anyway, I understand your point
[23:03] <jam> as for testing converting and then converting future work
[23:03] <jam> it should just amount to getting another copy of the ,v files, and running it again
[23:03] <jam> as long as you keep the conversion directory around
[23:04] <johnny> i'll be happy when pserver happens
[23:04] <johnny> then i can just pull into it
[23:04] <lifeless> jam: IMO anything we try to load must load or the tests must fail.
[23:07] <johnny> ok, i'm going to to get admin access to the project until pserver works
[23:08] <jam> johnny: i don't expect to have time to work on ;pserver: for quite a while, but it shouldn't be hard if you want to play with it
[23:08] <jam> And I'm happy to give answer questions
[23:08] <johnny> i'm still learning python
[23:08] <johnny> i don't work in a software job except php web devel
[23:09] <johnny> but our coffeehouse has about 5 projects we want to manage
[23:09] <johnny> yes.. a coffeehouse with folks who write code for it :)
[23:09] <johnny> bookstore/coffeehouse really..
[23:09] <lifeless> sounds cool
[23:31] <ubotu> New bug: #189771 in bzr "launchpad plugin tests broken" [Critical,New] https://launchpad.net/bugs/189771
[23:42] <abentley> lifeless: Any luck with the index stuff?
[23:49] <lifeless> abentley: in progress
[23:49] <poolie> i'm going to read spiv's network patch now
[23:49] <lifeless> don't byte off more ... groan sorry