[00:22] <lifeless> jml: http://pypi.python.org/pypi/testtools/0.7.8
[00:22] <jml> lifeless: yeah, someone filed a bug about it on the testtools launchpad page
[00:24] <lifeless> :P
[00:47]  * SamB looks for the bzr reconfigure command to turn an SVN checkout into a BZR checkout
[00:49] <SamB> huh. it apparantly took it a while to figure out it can't do that ?
[00:49] <SamB> that was with --checkout
[00:54]  * SamB wonders why doing `bzr info --verbose' in his svn checkout of Coq uses so much CPU
[00:56] <mwhudson> info -v does some fairly silly things
[00:56] <SamB> it says something about browsing branches
[00:57] <spiv> info -v is a bit expensive for bzr branches, I can imagine it would be a bit ridculous with svn branches...
[00:58] <SamB> it's gone and crashed on me
[00:59] <lifeless> SamB: bzr checkout fresh :). also perhaps file a bug on being abe to do the conversion via reconfigure.
[01:00] <james_w> upgrade?
[01:01] <SamB> james_w: what to ?
[01:02] <james_w> "bzr upgrade --default" might work
[01:07] <lifeless> or it might eat you
[01:07] <lifeless> 50-50 chance I reckon :P
[01:07] <lifeless> mwhudson: search is fixed
[01:08] <mwhudson> lifeless: ta
[01:09] <jml> maybe bzr should have a buildbot that tests a bunch of common plugins.
[01:11] <lifeless> abentley: http://pastebin.ubuntu.com/129601/
[01:13] <jml> spiv: so have you satisfied your curiosity about that patch yet?
[01:16] <SamB> lifeless: more likely that it will just leave me with a working directory that isn't
[01:16] <SamB> rather than eating me
[01:17] <lifeless> http://pastebin.ubuntu.com/129601/
[01:20] <SamB> is someone writing a "bzr gc" command ?
[01:22] <spiv> jml: which patch? ;)
[01:23] <spiv> jml: you mean https://code.edge.launchpad.net/~jeanfrancois.roy/bzr/url-safe-escape/+merge/3417 ? ;)
[01:23] <spiv> SamB: actually, we were talking about that last night.
[01:23] <spiv> SamB: the new 'fetch_spec' part of the fetch API may make it pretty easy to write.
[01:24] <mwhudson> lifeless: did you add multiply_tests and so on in the same landing as removing adapt_tests?
[01:24] <jml> spiv: yes that one -- the one that's blocking your review of my patch :P
[01:25] <spiv> jml: I don't actually see your patch
[01:25] <lifeless> mwhudson: yes
[01:25] <jml> spiv: that sucks.
[01:25] <thumper> what is revision.timezone stored as?
[01:25] <lifeless> mwhudson: also, separately, see lp:testscenarios
[01:25] <thumper> or what does 43200 translate to?
[01:25] <mwhudson> lifeless: that makes life difficult for us :/
[01:25] <spiv> thumper: 12 hours
[01:25] <lifeless> how so?
[01:25] <spiv> thumper: assuming that's seconds
[01:26] <thumper> is the timestamp on a revision stored at UTC?
[01:26] <spiv> (doesn't everyone know that there are 86400 seconds in a day?...)
[01:26] <mwhudson> lifeless: it's much easier if i can land a launchpad branch that passes with bzr-as-in-sourcecode and bzr.dev
[01:26] <jml> spiv: I sent it to<EMAIL_ADDRESS>[01:26] <mwhudson> last time i got spm to do a simultaneous landing i ended up getting phoned up when i was in a bar
[01:26] <jml> spiv: but I haven't got any bundle buggy mail about it.
[01:27] <thumper> mwhudson: sorry about that
[01:27] <spiv> jml: I haven't got it at all, I doubt bb has either
[01:27] <spiv> jml: I'll check the mailman moderation thingy
[01:27] <mwhudson> thumper: heh, it's ok, but it motivated me towards doing things the other way
[01:27] <mwhudson> maybe i can just copy-paste bits of testscenarios into launchpad temporarily...
[01:28] <thumper> spiv: is the revision.timestamp in UTC?
[01:28] <spm> mwhudson: but we were trying to make you look important by ringing your phone while you were in the bar!?!?! ;-)
[01:28] <spiv> jml: nope, not there either...
[01:28] <mwhudson> spm: heh heh
[01:28] <jml> spiv: maybe gmail is broken.
[01:29] <mwhudson> spiv, jml: "list server is currently backed up"
[01:29] <lifeless> thumper: no
[01:29] <lifeless> thumper: its in revision.timezone
[01:29] <jml> mwhudson: where's that from?
[01:29] <mwhudson> jml: #is on the private server
[01:29] <thumper> lifeless: so the utc time would be: revision.timestamp - revision.timezone ?
[01:29] <jml> mwhudson: ahhh
[01:29] <lifeless> thumper: there are normaliation functions around
[01:30] <thumper> lifeless: where?
[01:30] <lifeless> in bzrlib
[01:30] <thumper> lifeless: can you be a little more explicit or shall I just grep?
[01:30] <lifeless> I would be grepping to
[01:30] <thumper> ok
[01:31] <lifeless> I have a small page cache :)
[01:31] <thumper> lifeless: really?
[01:31] <thumper> lifeless: I thought it was large
[01:31] <lifeless> size is relative; I last looked at tz stuff about 2 years back
[01:32] <spiv> mwhudson: ta
[01:33] <mwhudson> btw, if someone wants to merge http://people.ubuntu.com/~mwh/extract-make-branch-scenarios-4109.patch
[01:33] <mwhudson> ,,,
[01:33] <mwhudson> ,,,
[01:33] <mwhudson> ...
[01:33] <mwhudson> !
[01:33] <mwhudson> (also currently somewhere between here and bb)
[01:35] <spiv> mwhudson: looks sane and near-trivial to me, I'll merge.
[01:35] <mwhudson> spiv: thanks!
[01:35] <mwhudson> oh, looks like robert already did :)
[01:37] <spiv> mwhudson: oh :)
[01:37] <spiv> mwhudson: even better.
[01:40] <lifeless> :P
[01:43] <lifeless> mwhudson: sorry re: single landing, but its easier for bzrlib to not have duplication
[01:47] <mwhudson> i just want to delete this code from lp :(
[01:52] <thumper> lifeless: I was just talking with jamesh about revision.timestamp
[01:53] <thumper> lifeless: observations on the lp scanner would be that it is recording the timestamp in utc
[01:53] <thumper> lifeless: but the code seems to indicate localtime
[01:53] <thumper> lifeless: now I'm confused
[01:55] <spiv> thumper: See bzrlib.repository.CommitBuilder's __init__, it defaults the timestamp to time.time(), which is seconds since the epoch, in UTC.
[01:56] <lifeless> ah so it is utc :P. oops :)
[01:59] <mwhudson> spiv: i would hope seconds since the epoch is timezone neutral!
[02:00]  * mwhudson sees jamesh making the same point in another place
[02:02] <jamesh> mwhudson: it measures time since the epoch assuming that every day has only 86400 seconds
[02:02] <SamB> hmm, say I'm writing an elisp program and I want to know what the default destination for "bzr send" is ... how should I do it ?
[02:04] <jelmer> SamB, hi
[02:04] <spiv> mwhudson: I'm just quoting the official docs :)
[02:04] <SamB> jelmer: hi!
[02:04] <jelmer> SamB: You filed a bug about being able to run "bzr reconfigure --branch" in a svn working copy
[02:05] <SamB> jelmer: yes
[02:05] <spiv> mwhudson: if you want to improve them, you're the one with the commit privs for python, not me ;)
[02:05] <SamB> I'm either for or against
[02:05] <jelmer> SamB, that doesn't make sense though, as subversion doesn't support working copies that carry a branch
[02:05] <jelmer> SamB, you would have to upgrade to a bzr format first
[02:05] <SamB> jelmer: oh. why first?
[02:05] <SamB> that sounds inefficient
[02:05] <jelmer> SamB, That's how reconfigure works
[02:05] <SamB> and also why does it take reconfigure so long to figure that out ?
[02:05] <spiv> SamB: "bzr upgrade" is really "bzr change-format"
[02:06] <jelmer> SamB, it's pretty much instantaneous here
[02:06] <SamB> plus, the bzr upgrade part doesn't seem to work either :-(
[02:06] <spiv> (but usually the only time you want to change format is to upgrade to a newer, better one, hence the name.)
[02:06] <SamB> jelmer: what SVN server ?
[02:06] <jelmer> SamB, gnome
[02:07] <SamB> huh. and you don't live in gnome?
[02:07] <jelmer> SamB, it might do some analysis of the repo first, but that should be cached
[02:08] <SamB> jelmer: I don't see why it needs to analyze the remote repository just to figure out it can't do a reconfigure in that directory!
[02:09] <jelmer> SamB, reconfigure probably looks at the branch tip before it tries to initialize a branch
[02:10] <jelmer> and that requires bzr-svn to do some analysis
[02:11] <SamB> well, okay, lets move on to Bug 340854
[02:12] <jelmer> SamB, I've just commented on that one
[02:12] <SamB> oh. I wish it didn't take so long for email to make it from launchpad to gecko ...
[02:14]  * SamB frowns at Low
[02:15] <jelmer> SamB, You can just checkout from svn in the proper format
[02:15] <SamB> jelmer: shouldn't it check whether or not it can finish the job before starting ?
[02:16] <SamB> it rather rudely moved all these directories in my checkout ...
[02:16] <SamB> oh, and I'm not quite sure what it failed to do, either!
[02:16] <SamB> why'd it leave me like this:
[02:16] <SamB>        control: Meta directory format 1
[02:16] <SamB>   working tree: Working tree format 4
[02:16] <SamB>         branch: Subversion Smart Server
[02:16] <SamB>     repository: Subversion Repository
[02:17] <SamB> isn't that a little insane ?
[02:17] <jelmer> SamB: This is what I mentioned in my bug report, there's no way for bzr-svn to control the upgrade process
[02:18] <jelmer> s/bug report/bug reply/
[02:18] <jelmer> SamB, Bazaar just assumes WorkingTree format 4 knows how to upgrade from a svn working copy
[02:18] <jelmer> but it doesn't and blows up
[02:21] <SamB> jelmer: well, now I'm bitching about how Bazaar just assumes that
[02:21] <johnf> excellent new bzrtools. Off a packaging I go
[02:22] <spiv> SamB: yeah, that's a real bug
[02:23] <spiv> SamB: not many users try to "bzr upgrade" bzr-svn branches to other formats, but we would like it to work.
[02:23] <Kobaz> how would i make bzr st and friends just show the filenames themselves without the path
[02:23] <SamB> any idea what the "conflict adding file" business was about ?
[02:23] <SamB> spiv: or at least fail at the beginning instead of half-way ?
[02:24] <Kobaz> like: cd /working_path/foo/bar; bzr st
[02:24] <spiv> SamB: that would be a start
[02:24] <Kobaz> and all the files are prefixed with their paths...
[02:24] <spiv> SamB: actually working would be better :)
[02:24] <Kobaz> even if i do bzr st *
[02:25] <TDT> Hey all.  I've been asking around a bit about this and spent anumber of hours on this.  I was just curious, was there a good way to basically create a "glue" between git and bzr?  TBH since I use git for 90% of my work, I'd prefer to be able to manage the bzr repositories I need to through git as well. I've read about the fast-export and fast-import, but have been having a lot of problems getting this all to work correctly.
[02:25] <SamB> and, of course, bzr-svn should be the package responsible for determining whether or not it works ...
[02:26] <spiv> SamB: right.  The problem is that the upgrade code in bzrlib isn't yet flexible enough to let bzr-svn hook in when it needs to.
[02:27] <jelmer> TDT, I'm working on a plugin called bzr-git that allows accessing git branches as if they were bzr branches
[02:27] <SamB> hmm, well, for some reason I decided to re-run the "bzr reconfigure --checkout" command after the "failed" upgrade run ... it hasn't failed yet, but there's still plenty of time for it to get around to failing ;-)
[02:28] <SamB> jelmer: oh, there isn't one yet?
[02:28] <SamB> and will it interoperate with git-bzr ?
[02:28] <jelmer> SamB, bzr-git is a work in progress but doesn't support e.g. writing to git yet
[02:28] <TDT> jelmer: *nod* yeah I've been using git-bzr for the opposite of that, it's out of development now,and...the guy has no reason to bother, heh.
[02:29] <jelmer> SamB: well, it won't recognize shared history with git-bzr
[02:29] <SamB> hmm. git-bzr isn't in my package database. maybe I don't care.
[02:30] <TDT> http://github.com/pieter/git-bzr/tree/master -- this is the project I was talking about
[02:30] <TDT> It's not standard included with git-0core, it's an addon.  I don't know if others exist
[02:31] <jelmer> TDT, yeah, I'm aware of it
[02:31] <jelmer> TDT, it basically allows access to bzr branches from git, whereas git-bzr allows access to git branches from bzr
[02:32] <SamB> jelmer: you got your package's name backwards
[02:32] <TDT> jelmer: Yeah, but I'm kinda assuming both rely on the git-fast-export/import and bzr-fast-export/import, am I right?
[02:32] <jelmer> TDT, no, bzr-git doesn't use fastimport/fastexport
[02:32] <TDT> Hmm, definitely perked my interst in how you got that to work then
[02:33] <jelmer> SamB, whoops, sorry - it's getting late :-)
[02:33] <TDT> I want something that works the opposite, but it relies on way too many dependencies that it's causing issues..been a real pain anyways.  Been reading way too much on it, it may turn into something I need to work on more over time.
[02:33] <SamB> hey, it's an easy mistake to make, especially in that conversation ;-)
[02:34] <jelmer> TDT: what do you mean with "something that works the opposite" exactly?
[02:34] <jelmer> TDT, bzr-git does more than just fetching from git into bzr and vice versa
[02:34] <jelmer> TDT, it allows all of the Bazaar API to be used with git repositories
[02:34] <jelmer> (or that's the goal, anyway)
[02:35] <TDT> jelmer: Yeah, I understand that.  Your solution goes from the idea of using bzr as the baseline.  My goal is to do the opposite, use git to read bzr branches and use git commands and "push" changes to a bzr bound branch.
[02:35] <SamB> jelmer: will it allow bzr upgrade --format=git ?
[02:35] <jelmer> SamB, No, as the upgrade code in bzr isn't flexible for that yet as we've just concluded :-)
[02:36] <jelmer> SamB: In due time, yes
[02:36] <SamB> jelmer: but you said it was the target format that was responsible for providing the conversions
[02:36] <SamB> so I figured that might be okay then ;-)
[02:36] <johnf> can someone check http://inodes.org/johnf/debs/bzr before I upload them to beta ppa
[02:36] <jelmer> SamB: Right now the target format is responsible, it should be a combination of the source and target format though
[02:36] <jml> spiv: https://lists.ubuntu.com/archives/bazaar/2009q1/054539.html
[02:36] <SamB> jelmer: yeah
[02:38] <jelmer> TDT, I thought git-bzr just depended on ruby and fastimport/fastexport ?
[02:41] <TDT> jelmer: it does, it's going by a different idea than what you're doing - which is why I'm pretty interested in what you're doing :)  For whatever reason the whole fastimport/fastexport thing is horribly broken for me right now
[02:42] <jelmer> TDT: Something like bzr-git wouldn't be possible in git, as it doesn't have an API that's abstracted like bzr
[02:44] <jelmer> TDT: It's just a collection of command-line tools with a specific file format
[02:44] <SamB> hmm. too bad git-fast-export doesn't support ASCII armoring of binaries ...
[02:52] <jelmer> SamB, hmm
[02:52] <jelmer> SamB, the fact "bzr upgrade" breaks the working copy is a bit annoying indeed, I've upgraded the bug to medium
[02:57] <SamB> :-)
[02:57]  * SamB wonders if this second "bzr reconfigure" is going to work
[02:58] <jelmer> SamB, it might, but only because the working tree is now workingtree format 4
[02:58] <SamB> yeah, I figured that was why it had gotten as far as it has
[02:58] <SamB> [######/             ]  18995kB @    2kB/s | copying revision 3363/10231
[02:59] <jelmer> that looks about right
[02:59] <SamB> I'm just wondering if it's going to (a) crash part-way through complaining about
[02:59] <SamB> bzr: ERROR: bzrlib.errors.NoSuchRevision: <bzrlib.plugins.svn.revids.RevisionIdMapCache object at 0x89ee70c> has no revision svn-v4:c7f1d35c-780e-0410-8b2b-bc164f6bbeca:coq-local/trunk:8620
[03:00] <SamB> or something else wierd
[03:00] <SamB> or ... will it actually work ?
[03:00] <jelmer> SamB: Is there any reason you're upgrading an existing svn working copy rather than just doing "bzr branch <remote-svn-url>" ?
[03:01] <SamB> jelmer: well, I might have some local changes
[03:01] <SamB> that, and I like trying things to see if they work
[03:02] <jelmer> SamB, well, the latter is certainly appreciated :-)
[03:03] <SamB> and if they don't, I like them to fail as gracefully as possible
[03:03]  * SamB goes to bed
[03:03] <jelmer> SamB, bug reports like these are useful, even if they're blocked by bzr :-/
[03:03] <SamB> you're welcome
[03:10] <johnf> anyone? can someone check http://inodes.org/johnf/debs/bzr before I upload them to beta ppa
[03:11] <lifeless> johnf: if they work for you, jfdi
[03:11] <lifeless> -> lunch
[03:12] <johnf> fair enough. Only real issue is people will need a newer builddeb package
[03:12] <james_w> why's that?
[03:14] <james_w> <- lunch
[03:14] <johnf> james_w: it works but has an annoying deprecation error
[03:14] <johnf> usr/lib/python2.5/site-packages/bzrlib/plugins/builddeb/revspec.py:68: DeprecationWarning: Modifying SPEC_TYPES was deprecated in version 1.12.
[03:14] <johnf>   SPEC_TYPES.append(RevisionSpec_package)
[03:14] <johnf> about to go see if there is a bug
[03:15] <james_w> it's fixed
[03:15] <johnf> excellent
[03:15] <james_w> it's just a warning though, so it shouldn't prevent things working
[03:26] <mwhudson> jml: i'm using lp-open a lot now, thanks for doing that! :)
[04:23] <lifeless> poolie: AllowDeactivateGrabs in man xorg.conf
[04:25] <jamesh> note that that setting effectively kills the security of the screen lock
[04:25] <jamesh> kill the grab and alt+tab away from the screen saver
[04:25] <poolie> because people can send input to tasks behind it?
[04:25] <poolie> heh
[04:26] <poolie> DisableXorgBugs true
[04:27] <jamesh> it isn't a bug: the feature works as advertised.
[04:27] <jamesh> and there is a reason it is disabled by default
[04:28] <lifeless> jamesh: actually, there is a new api for screen savers
[04:28] <jamesh> if you need it and are not developing X software that performs grabs, then that is a bug
[04:28] <lifeless> An API was written to such cases.  If you enable
[04:28] <lifeless>               this option, make sure your screen saver/locker is updated.
[04:28] <lifeless> jamesh: there are bugs; see under software
[04:29] <lifeless> for instance, drag and drop in gnome takes grabs
[04:29] <bob2> and firefox
[04:52] <mwhudson> hm
[04:53] <mwhudson> what are the chances that the latest change to bzr.dev will end up in 1.13?
[04:53] <mwhudson> i guess i can always cp it onto the branch of bzr we use
[05:04] <james_w> mwhudson: should be pretty uncontroversial for a cherry pick to the release branch if you want to mail the list about it
[05:09] <poolie1> mwhudson: what was it?
[05:11] <lifeless> pulling out the branch scenarios generation to a helper
[05:11] <mwhudson> poolie1: moving the generation of branch scenarios into a separate function
[05:36] <lifeless> mwhudson: did you get the chk repo?
[05:37] <james_w> vila: p:~james-w/+junk/favourites-package
[05:37] <james_w> with an l of course
[05:38] <johnf> should we remove the feisty 1.12 packages from the beta ppa seeing as feisty is now EOL?
[05:40] <lifeless> johnf: so, bzr-builddeb, what about it?
[05:40] <johnf> lifeless: works fine just a deprecation warning
[05:40] <johnf> which is already fixed in trunk
[05:41] <lifeless> johnf: are you going to upload the fixed version to the ppa?
[05:41] <johnf> that was my next question. bzr-beta ppa doesn;t currently have builddeb packages. Do we want it to?
[05:41] <lifeless> let me do a straw poll
[05:41] <johnf> I vote yes and am happy to make it happen :)
[05:42] <johnf> jelmer: are you going to create new bzr-svn packages in the beta-ppa or would you like me to do it?
[05:44] <lifeless> johnf: so, mostly 'shrug', one 'no', couple of yeses
[05:45] <lifeless> so - do it, I think. I'll wear the blame if its wrong :)
[05:45] <johnf> cool
[05:46] <johnf> lifeless: next thing is best way for me to get my packaging changes commited
[05:47] <johnf> I could just branch those repos into beta-ppa or maybe we just move them
[05:47] <johnf> probably makes more sense to have them there since most of the packaging work will happen in beta and then the final packages can just be copied to the bzr ppa
[05:48] <vila> james_w: thanks !
[05:48] <james_w> vila: no problem, let me know if the instructions aren't clear
[05:53] <vila> james_w: I'll do that
[05:58] <lifeless> johnf: let me rename them
[05:58] <lifeless> johnf: The price is that you update the docs and put forward a [MERGE] with the changes
[05:59] <johnf> I already have a heap of edits for ppa.txt that I'll put up soon
[05:59] <johnf> also some changes to the packaging scripts
[06:00] <lifeless> johnf: what are the branches you need access to
[06:01] <johnf> lifeless:  lp:~bzr/bzr/packaging-* although you can probably kill off feisty and  lp:~bzr/bzrtools/packaging-*
[06:02] <lifeless> oh hmm
[06:05] <lifeless> johnf: ok, the easiest thing here is for you to join the bzr team
[06:05] <lifeless> you'll get bugmail; but you have procmail ? :)
[06:05] <lifeless> johnf: the ppa docs about joining the beta team to be able to do this are probably necessary but not sufficient
[06:06] <johnf> I have sieve but yes :)
[06:06] <lifeless> ok
[06:06] <johnf> is it easier to just branch them into beta an pull every so often?
[06:08] <lifeless> no, easiest is to give you lots of mail
[06:09] <johnf> fair enough
[06:10] <lifeless> if thats ok
[06:11] <lifeless> in a technical sense we probablt want a bzr-ppa team, which has bzr as a member, and owns all th epackaging branches
[06:11] <lifeless> and is a member of bzr-betta-ppa, bzr-ppa, etc etc
[06:11] <lifeless> but right now, JFDI time :)
[06:11] <lifeless> whats your lp account name?
[06:12] <lifeless> johnf: ^
[06:13] <johnf> lifeless: johnf-inodes
[06:14] <lifeless> done
[06:32] <spiv> New way to break the test suite: put a bzrdir in /tmp with a default_stack_on in its control.conf
[06:32] <lifeless> slick
[06:32] <Smiskis> Bzr or Git? How do they differ? Why do you prefer Bzr?
[06:33] <lifeless> http://bazaar-vcs.org/BzrVsGit
[06:45] <Smiskis> I heard about an SCM that was sprung from "mathematical" theory - with operations of more "logical" nature, supposedly created by academic people... anyone know what im talking about?
[06:47] <lifeless> possibly monotone, or codeville, or darcs
[06:51] <Smiskis> must be darcs
[06:51] <Smiskis> thanks lifeless
[06:57] <lifeless> Smiskis: no probs
[07:05] <poolie1> vila: "Wed Mar 11 06:43:20 2009 UTC: Vincent Ladeuil<EMAIL_ADDRESS>Request for non-PQM managed branch." ie your branch is going to bounce
[07:08] <SuperMMX> pwd
[07:13] <spiv> poolie1: same for yours!
[07:13] <poolie1> i know
[07:30] <poolie> here's an interesting thing: orcadas got noticeably faster when it was upgraded to hardy
[07:30] <poolie> some combination of kernel and python
[07:30] <poolie> pqm could possibly get faster too
[07:42] <lifeless> poolie: running parallel tests would probably be faster too :P
[07:43] <bialix> hi, anybody with Python 2.6 installed? I need a little help to check 2.6 behavior
[07:43] <spiv> bialix: sure
[07:43] <spiv> poolie: ooh, you broke bzr+ssh :P
[07:44] <bialix> can you check stream attribute as I shown here: http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/53539
[07:44] <bialix> I'd like to finish my patch, because igc is busy
[07:46] <poolie> spiv, do you get a failure in __repr__?
[07:49] <james_w> bialix: python 2.6 shows the same behaviour here as in your email
[07:50] <bialix> thank you!
[07:50] <bialix> I'll add simple smoke test for that bug and will send the complete patch then
[08:58] <clemente> Hi, a patch I sent has to be marked as superseeded by another one in Bundle Buggy. I don't have a login. How do I proceed?
[10:33] <George2> hi
[10:34] <George2> what's the difference between bzt init and init-repo? am i right in thinking that to create a repo, i can either bzr init, and if no repo exists in the parent dir, it will create one in the current dir?
[10:37] <SamB> init-repo doesn't create a branch
[10:38] <SamB> that's the main difference
[10:38] <SamB> that, and init-repo creates a repository whether you're in one or not, I assume ...
[10:40]  * SamB wonders what computer is pulling down data at 200K
[10:40] <fullermd_> init-repo creates a shared repository, that later branches can use (and share).
[10:41] <fullermd_> init creates a branch, which will use an existing shared repo if there is one, or create an internal [private, non-shared] repo if there isn't.
[10:42] <SamB> oh, it can't be shared ?
[10:42] <fullermd> init won't make a shareable one, no.
[10:42] <fullermd> You could probably trick it into being sharable later by manual ad-hackery in the bzrdir.  But I don't recommend it.
[10:42] <SamB> what's the difference between a shareable repo and an unshareable repo?
[10:43] <fullermd> A shareable repo can be used in common by multiple branches.  An unsharable one can't (and generally doesn't exist except hidden inside the branch that owns it)
[10:43] <fullermd> Basically, a share repo is the only sort of repo you ever see or interact with in any way.
[10:44] <fullermd> You never create a non-shared repo, it just happens when you make a branch that can't find an existing shared repo to use.
[10:45] <fullermd> This also means that colloquially, any time somebody talks about a "repo", they almost certainly mean an explicitly-created shared repository, unless they're discussing internals or relatively arcane implementation details.
[10:46]  * SamB contemplates bzrcrush
[10:52] <George2> thanks guys, that helps a bit!
[10:53] <George2> a la git, switching from one branch to another in the same dir is simply a matter of checking out the different branch, how do i do this with bzr? the init-repo --no-tree option is confiusing me
[10:54] <fullermd> That's probably a side effect of init-repo --no-trees not really having much to do with that problem   :P
[10:54] <fullermd> (well, it's usually a step in the process, but doesn't directly bear on it)
[10:54] <George2> oh
[10:54] <George2> trying to wrap my head around the user guide
[10:55] <fullermd> The central command to think about in that case is 'switch', which throws a working tree from one branch to another.
[10:55] <George2> is the only way to create a separate branch in a new dir and then merge?
[10:55] <SamB> George2: did you see the GitStyleBranches wiki page?
[10:55] <George2> SamB: no?
[10:55] <SamB> well, it's kind of new
[10:55] <George2> fullermd: oh, so just simply bzr switch newbranch
[10:55] <fullermd> Yah.
[10:56] <George2> wow, nice
[10:56] <fullermd> Details like setting up a --no-trees shared repo are often parts of _setting up_ a layout where you later do that.  But they're not strictly speaking necessary parts of it.
[10:56] <George2> what's the no-trees option for then?
[10:56] <SamB> George2: are you using a lightweight checkout?
[10:56] <George2> SamB: no, trying to get my head around normal checkouts!
[10:56] <SamB> oh, it just keeps your storage branches from having working trees
[10:57] <George2> lightweight is history-less right?
[10:57] <fullermd> Basically, it all makes a bit more sense if you grok the triumverate of Working Tree, Branch, and Repository.
[10:57] <SamB> George2: oh ;-)
[10:57] <SamB> lightweight is good for doing git-style switchable branch checkouts, actually
[10:57] <fullermd> Don't worry about lightweight vs heavy checkouts, at least at the start.  The differences shouldn't affect the semantics (if they do, it's probably a bug), and it can be a little confusing.
[10:57] <SamB> fullermd: oh?
[10:57] <George2> fullermd: the userguide is great from what i've read - half way so far, but the intro about explaining the terms is perhaps the only weak part
[10:58] <SamB> what about the parent/push paths ?
[10:58] <fullermd> (not to say the differences are unimportant, but..)
[10:58] <SamB> I'll agree that other differences are probably bugs
[10:58] <George2> doesn't lightweight only affect what is pulled - ie. branch history?
[10:58] <fullermd> See, this just goes back to my periodic bitchings about leaky abstraction on [heavy] checkouts   :p
[10:58] <SamB> but don't try to convince me that bzr isn't full of bugs of that sort ;-)
[10:59] <fullermd> George2: Basically, just use this rule of thumb; if the branch is on the local machine, use a lightweight checkout.  If it's on a remote machine, use a regular (heavy) checkout.
[10:59] <George2> oh
[10:59] <SamB> anyway, if you have a --no-trees repo with your branches in it in the next dir over, you still have all the history right there ;-)
[10:59] <George2> well i'm looking for a single-dev local maching setup
[10:59] <SamB> I mean, assuming that's what the lightweight checkout is bound to
[10:59] <George2> except depending on the project, my workflow may change, so i'm just trying to wrap my head around it all!
[11:00] <George2> should i have a repo for each project, or can i have a projects dir?
[11:00] <SamB> anyway, if you do look at the GitStyleBranches page, please give any comments about what isn't clear enough
[11:00] <George2> SamB: url?
[11:01] <fullermd> Generally, a repo per project is a good demark.
[11:01] <SamB> I don't bother unless I actually want more than one branch
[11:01] <fullermd> You could stick everything in one repo.  Or you could not use shared repos at all.  Or anywhere in between.
[11:02] <fullermd> But sharing a repo across projects generally gives very little gain.  And using more than a very few branches of one project without one is pretty wasteful.
[11:02] <SamB> http://bazaar-vcs.org/GitStyleBranches
[11:02] <SamB> George2: I can see why you wanted the URL
[11:02] <SamB> it doesn't really google too well yet, does it?
[11:04] <SamB> google's top hits on the wiki are RecentChanges and WordIndex ...
[11:04] <George2> fullermd: i'm looking for a way to store a cms core, and modules for the cms. i essentially would like to be able to checkout the core files, and then the modules. but i maintain some modules, so can i have a repo inside the modules repo for each module i maintain?
[11:05] <fullermd> Well, you can put one shared repo under another in the filesystem.  But they don't have anything to do with each other.
[11:05] <fullermd> I'd generally discourage that, just because it can open up chances for you to get confused about what's where.
[11:06] <George2> SamB: first line: [...] it's true than many Git users like its approach and it does have benefits worth noting: -- add some context, does the quote refer to git or bzr?
[11:06] <SamB> George2: refers to git
[11:06] <George2> fullermd: oh, so what solution would you suggest?
[11:06] <SamB> at least, I assume
[11:07] <SamB> George2: is that what you thought?
[11:07] <George2> should i have a repo for others modules, and a repo for mine?
[11:07] <George2> SamB: after reading a bit yeah, but it's not immediately clear. this is your site right?
[11:07] <George2> oh no, sorry - hehe
[11:07]  * George2 checks the url ;)
[11:07] <SamB> I did make the wiki page though
[11:08] <SamB> but I didn't write that part
[11:08] <SamB> copied it from the linked section
[11:08] <fullermd> Well, a lot depends on just how much breadth you get.
[11:08] <fullermd> I mean, if you only have one branch of a given module, a shared repo buys you nothing.
[11:09] <fullermd> If two modules share no history, then having them use a common repo also buys you nothing.
[11:09] <George2> fullermd: for others modules, i'm just looking for a place to esesntially dump them i guess, but i'd probably have a few branches for my modules
[11:09] <SamB> shouldn't there be a flag to "bzr init" that tells it not to use a shared repo ?
[11:09] <SamB> I can't seem to see it in the HEAD
[11:10] <SamB> well, it is the HEAD as of the night before last ...
[11:10] <fullermd> Modules are pretty small, presumably, so history probably doesn't eat that much space or I/O.  I'd suggest just ignoring shared repos for them for right now, and letting them be standalone branches.
[11:10] <George2> SamB: yeah there is, i think i remember reading about it
[11:10] <fullermd> Then you can see what works and where you might benefit from repos, and retrofit them in later.
[11:10] <SamB> all these branch format flags are a bit distracting
[11:10] <fullermd> I don't think it does.  You could reconfig it afterward.
[11:11] <SamB> I think the user should be advised to see "bzr help upgrade" for the documentation for those, personally ...
[11:12] <SamB> it's too bad you can't use javascript to make things collapsable in terminal-based UIs ;-P
[11:12] <George2> ok so i'm confused fullermd! so you're suggesting a shared-repo in say /modules. and then each module (~40kb) is a subdir of /modules?
[11:12] <SamB> George2: not really
[11:13] <SamB> the shared repo there wouldn't really get you anything
[11:13] <fullermd> Well, what I'm really suggesting is a bit more meta than that; don't worry about shared repos there period, at least for now.
[11:13] <SamB> yeah.
[11:13] <fullermd> Shared repos don't have semantic value; they save you storage space and I/O bandwidth.
[11:14] <fullermd> But everything else (there are some arcane exceptions, but you don't care) will act exactly the same whether the branches share a repo or not.
[11:14] <SamB> if that happens to be inside one, no big deal, but it won't buy you anything to explicitly create one there
[11:15] <fullermd> And it's not very difficult to reorganize things later to add shared repos around parts of the branch set.  So your initial decisions in that area aren't cast in stone.
[11:15] <SamB> fullermd: and the exceptions are going to be far fewer and farer between than the differences between lightweight and heavyweight checkouts
[11:15] <fullermd> They're not even cast in foam latex...
[11:15] <George2> mhh, i wonder, instead of having a separate core and modules repo, maybe combinging the two would be best
[11:15] <SamB> George2: you mean having them all in one branch ?
[11:16] <fullermd> I think you're worrying a little too much about repo boundaries.  Maybe you're thinking SVNish, where the repo is an important semantic boundary?
[11:16] <George2> exactly
[11:16] <SamB> or darcs or git?
[11:16] <George2> well i'm trying to get my head around a workflow that will be benficial
[11:16] <George2> i've just come from git, it was too limiting
[11:17] <fullermd> Or gitish, where it's an important (in a totally different way, and much more malleable) boudnary as well.
[11:17] <SamB> well, are the modules developed seperately from eachother?
[11:17] <George2> SamB: yeah they are
[11:17] <SamB> but he's not scarred enough to come from tla
[11:17] <George2> SamB: but to me as they're not my modules, doesn't really affect me
[11:17] <George2> tla?
[11:17] <SamB> George2: well, where are you getting them from?
[11:18] <SamB> George2: you don't want to know ;-)
[11:18] <fullermd> How 'bout this; unless you have a component with "a lot" of history (>50 megs, maybe), that you'll have more than a few branches of, forget init-repo exists.
[11:18] <George2> SamB: a cvs repo / downloading from modules site
[11:18] <George2> hehe - that simple
[11:18] <George2> the userguide doesn't really mention that at all fuller
[11:19] <SamB> and who is going to access the bzr branch(es) you are making?
[11:19] <George2> SamB: just me
[11:19] <fullermd> Well, a great thing about bzr is how flexible it is, and how many ways you can combine the pieces depending on your specific needs.
[11:19] <SamB> well, just do whatever then
[11:19] <fullermd> One terrible thing is that it's very flexible, and you can combine the pieces a lot of different ways depending on your specific needs.
[11:20] <SamB> I might make a different branch for each source of code
[11:20] <fullermd> So it gets really hard to say "just do X, Y, Z" without reference to a specific case.
[11:20] <George2> fullermd: its flexibility is what attracted me here
[11:20] <fullermd> In this case, the CMS core may be large (in terms of the tree size, and in terms of history size), and you may have many branches of it hanging around.
[11:20] <fullermd> So a shared repo can gain you a lot there.
[11:21] <SamB> maybe one would be an svn checkout (BZR format, probably -- it's faster ;-)
[11:21] <fullermd> The modules, though, are presumable small (in both tree and history), won't have common history with each other, and you probably won't have all that many branches of any individual one of them.
[11:21] <George2> fullermd: drupal. the core is about 2mb i believe, currently 3 major versions, 1 of them still in dev
[11:21] <fullermd> So repos aren't necessarily going to gain you very much.  And working out just where they can be put to help you out, especially in advance, is probably more trouble than it's worth.
[11:22] <SamB> I wouldn't involve any repos unless you find yourself with a couple of branches of the same module
[11:22] <George2> the modules, are small, and i just want a repo to dump them and pull out of as necessary. though the modules i maintain, i'd like to have a separate repo for each i guess
[11:22] <fullermd> OK, there you're using "repo" in a way that doesn't really mean anything (or anything like a repo, anyway) in a bzr sense.
[11:23] <SamB> of course, setting all the checkouts up might be a bitch, so maybe I would just dump the modules all in one branch ...
[11:23] <SamB> fullermd: I think he means branch
[11:23] <George2> a bzr branch != cvs branch
[11:23] <fullermd> Well, more specifically, probably treeless branch.
[11:23] <SamB> hmm ?
[11:23] <fullermd> Though whether the treeless really matters much may be questionable.
[11:24] <SamB> George2: describe how you would like to use the VCS setup
[11:25] <George2> ok, so i would like to be able to checkout a version of drupal with related modules for that version to assist in a speedy setup of a site. i'd also like to be able to log changes to my modules that i make for that core version of drupal
[11:26] <fullermd> George2: I would suggest chewing a bit on WT, Branch, and Repo until you grok them separately.  Then it'll be easier to work out which you want where, which makes it real easy to figure out how to lay things out.
[11:26] <George2> there are perhaps 40 or so modules, and about 5 of mine
[11:26] <George2> ok
[11:26] <SamB> would you mind terribly having to check each of yours out seperately?
[11:27] <George2> samb, prolly not
[11:27] <SamB> like, would it be okay like this: 1) check out drupal 2) check out modules directory containing foreign modules 3) check out each of my modules
[11:27] <George2> i'd like of course to have the ones i checkout to be two-way synced up to the repos
[11:27] <SamB> where by "my" of course mean your
[11:28] <George2> SamB: i'd like to checkout a version of drupal, and get all teh modules for that version
[11:28] <SamB> oops. I forgot an I in that last sentence
[11:29] <SamB> George2: well, this way might make it easier to track bugfix releases
[11:29] <SamB> also you could set up a script for it or something ...
[11:29] <SamB> how many of these websites do you make?
[11:30] <George2> ohhh
[11:30] <George2> so Repo -> working tree -> branch
[11:30] <George2>               \> another working tree -> branch etc ?
[11:30] <fullermd> Another option (just to complexify things) is to create 'rollup' branches, where you combine a given drupal version with whatever modules make sense for that version, merging from the various sources as necessary, so you have a single branch to work from for deployments.
[11:31] <SamB> yeah
[11:31] <fullermd> (ignore that of course; I'm just making trouble  :p)
[11:31] <SamB> I thought of that
[11:31] <George2> fullermd: so a middle inbetween branch
[11:32] <George2> so all sources, combing sources, and new projects are a checkout of the combining sources
[11:32] <fullermd> Not exactly...   a WT "points" to a branch, and a branch "points" to a repository.
[11:32] <George2> i've thought about that for git
[11:32] <fullermd> (generally the pointing is implicit rather than explicit, but...   implementation detail)
[11:32] <SamB> George2: how did you want to do it with git?
[11:33] <George2> oh so each branch has its own wt
[11:33] <fullermd> A WT is where you have working files, that you can read or run or print or compile or make changes to or whatever.
[11:33] <SamB> George2: can have
[11:33] <fullermd> A branch defines a particular history, the past revisions, and what revision is the current 'head'.
[11:34] <fullermd> A repository is basically just a big bucket full of revisions, with no ordering or anything like that.
[11:34] <SamB> you can think of a branch as being a bit like a one-head git repository
[11:35] <fullermd> So phrases like "check out a repository" don't make any sense in bzr.  You can only "check out" a revision, but a repository is just a big sea of revisions, with no indication of which one you might be interested in.
[11:35] <fullermd> A branch [practically] necessary has a repository somewhere; otherwise it wouldn't have anywhere to store revs.
[11:35] <George2> i see
[11:35] <fullermd> The branch serves to tell you WHICH revs are important in a given case, by saying "this is the current head"
[11:36] <SamB> well, yeah, a branch with no repository is like a broken symlink
[11:36] <SamB> even an SVN branch needs a repository
[11:36] <George2> so the branch indexes what revisions are important to that particular branch from whichever repo? hence the need to refer to the repo
[11:36] <fullermd> Right.
[11:37] <fullermd> This is fundamentally the same as git, though different pieces are visible.
[11:37] <fullermd> The git moral-equivalent-ofrepo is also a giant bucket full of revisions, and the 'branch' is a pointer to one (via its SHA1 hash)
[11:37] <fullermd> The branch is just a file hidden under .git/, rather than an explicit exterior directory.
[11:38] <ronny> gits is more like a buked of "objects"
[11:38] <George2> ok, so essentially, would it make sense to have a repo that stores drupal and the related modules for that version. with each version being a branch. and a repo for my modules with each module being a branch?
[11:38] <fullermd> Well, it's a bucket of somethings, and the branch lets you refer to somethings.  Don't get technical  :p
[11:38] <SamB> ronny: well, a lot of those objects are commits
[11:39] <SamB> and most of the rest are referenced only via commits
[11:39] <ronny> SamB: more of them are tree's and blobs
[11:39] <fullermd> George2: Think of it in terms of revisions.  If two branches share no revisions, then having them use the same repository doesn't gain anything.
[11:39] <SamB> those can be viewed as part of the commits, for the most part
[11:40] <fullermd> So, e.g., having drupal and some module sharing a repo doesn't save you anything, versus having them be standalone (and thus each having its own repo internally)
[11:40] <fullermd> On the other hand, having 2 branches of drupal share a repo probably gains a lot, because presumably a lot of the history is common, up to the point where the branches diverged.
[11:40] <fullermd> So, in one sense, it makes more sense to have the various branches of drupal grouped together one place, and the modules in another.
[11:41] <George2> fullermd: i understand that - kindof - but having a repo for each module is overkill no?
[11:41] <George2> i don't particularly want to have to set up 40+ repos just for the modules
[11:41] <fullermd> Probably.  Unless the module is big or has a lot of branches, it's probably more trouble than it's worth.
[11:41] <fullermd> Well, that's why I said don't set up repos for the modules period  ;)
[11:42] <George2> fullermd: but i want the modules to be associated with the core version of drupal!
[11:42] <fullermd> Repos don't do any sort of association.
[11:42] <fullermd> All they do is share storage space.
[11:42] <fullermd> Like I said, I think you're assigning way too much meaning to them.
[11:43] <George2> probably
[11:44] <fullermd> (by 'repo' in this part of the discussion I mean "shared repo" the thing you create with init-repo.  In the earlier WT/Branch/Repo discussion, I meant it as the underlying object in the bzr gestalt)
[11:45] <fullermd> So, let's suppose you have a /work where all this goes.
[11:45] <fullermd> You have /work/drupal/1.0 and /work/drupal/2.0 and /work/drupal/3.0 (or whatever branches of drupal there may be)
[11:45] <George2> actually. i'm mistaken. i think i do need a middle ground
[11:45] <fullermd> And also /work/modules/foo and /work/modules/bar and so on.
[11:45] <fullermd> Using init-repo to make /work/drupal a shared repository can be a useful thing to do, since those branches will have common history.
[11:46] <fullermd> But for now, I'd just totally ignore init-repo in the /work/modules/ hierarchy.  Just let them all be standalone branches, with the internal private repos 'init' (or 'branch' or however they come into being) creates for them.
[11:46] <George2> ie. i have a drupal core repo, i have a modules repo and for each major drupal core i have a set of plugins, and then a repo for each of my modules. if i then set up a repo to store checkouts as necessary from the specific branch from each repo, and then i checkout from this  that should work right?
[11:47] <fullermd> And ignore init-repo _conceptually_ in /work/drupal/ too.  It doesn't make anything act differently from having those be standalone branches too, just a bit faster and a bit smaller.
[11:47] <fullermd> No, not a modules repo.  No repo.  Ixnay on the eporay.  There Is No Repo.   :)
[11:47] <fullermd> Just a directory under which you have a lot of branches for modules.
[11:48] <George2> damnit! but a repo stores branches no?
[11:48] <fullermd> No, a repo stores revisions.
[11:48] <awilkins> A branch is really just a pointer to one revision
[11:49] <fullermd> A shared repo can be used by multiple branches.  That's what sets it (what you make explicitly with init-repo) apart from the Repository that's a underlying piece of how bzr works.
[11:49] <fullermd> Branches (so to speak) store themselves.
[11:50] <fullermd> Mmm.  Clear as mud?  Maybe we should back up...
[11:50] <George2> ok, i didn't explain that properly. i understand about a drupal repo to share revisions
[11:50] <SamB> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2298#a2298
[11:51] <George2> but then for each drupal core, i could have a branch with a set of modules in for that specific core right?
[11:51] <fullermd> In day to day operations, the repo is completely uninteresting.  Nothing you do will ever interact directly with it.
[11:52]  * fullermd suspects we're talking about too many things at once...
[11:53] <SamB> any idea how to fix the conflicts in the above-pasted "bzr info" output?
[11:53] <George2> ok, so in its simplest terms at the most basic level. a branch for drupal 5, branch for 6, branch for 7. branch for modules for 5, branch for 6 modules, branch for 7 modules. branch for each of my modules?
[11:54] <George2> fullermd: i think i'm locked too much into the cvs / svn workflow idea
[11:55] <fullermd> The big thing that bites you there (next to the importance of repos, anyway) is that in CVSVN, you tend to have one big tree that you check out and work on parts of.
[11:55] <SamB> some people even check out all the branches at once
[11:55] <fullermd> Whereas in bzr, you pretty much always work with whole branches, never with parts of branches or with conglomerations of multiple branches.
[11:56] <SamB> I dunno why
[11:56] <SamB> I had assumed at first it was ignorance ... but one guy said he did it that way on purpose ...
[11:57] <fullermd> So in SVN, the repo boundary is vital, while branch boundaries are not only unimportant, they're terribly ambiguous.
[11:57] <fullermd> While in bzr, the repo boundary is utterly meaningless, while the branch boundary is a hard line.
[11:57] <SamB> nevermind that people might make a branch based on only part of the another branch ...
[11:57] <SamB> or put a readme.txt where you might expect a branch
[11:57] <SamB> or ...
[11:58] <George2> i'm starting to get the meaningless-ness of the repo now
[11:58] <fullermd> So how you want to subdivide branches (branch of all 5 modules, branch for each individual 5 module, etc) depends on at which granularity you'll want to work with them.
[11:58]  * SamB is talking about the firebug repo
[11:58] <George2> the repo is just an abstracted place to store revisions which is unimportant
[11:58] <SamB> unimportant in theory, yes
[11:58] <SamB> and in practice at small sizes
[11:59] <fullermd> Right.  The Repository (object) is something that's always around one way or another, and directly stores the history.
[11:59] <George2> fullermd: well having separate branches for each would be foolish as i don't particularly want to track each update. if an update is broken, i can rollback from the drupal module cvs
[11:59] <fullermd> The repository (shared repository, thing you make with init-repo) is something you use to share space and I/O among related branches, but otherwise makes nothing act differently than if the branches were completely standalone.
[11:59] <George2> whereas for my modules, i'd like to eb able to track each commit
[12:00] <George2> fullermd: i understand that now - it's just an optimising process
[12:00]  * fullermd nods.
[12:00] <SamB> does drupal really use CVS ?
[12:00] <George2> thanks for sticking with me :)
[12:00] <George2> aye
[12:00] <SamB> why the heck?
[12:00] <fullermd> Yeah.  How you split those branches is pretty much dependant on how you'll expect to be updating/working on them, etc.
[12:00] <George2> no idea
[12:01] <fullermd> At one point, drupal had a semi-official bzr mirror.  I don't know whether that's still kept up or not, though.
[12:01] <George2> fullermd: ok, so for each new drupal project, if i check out 40 modules, but decide i only want 10, if i remove them, it would affect the parent branch right?
[12:02] <George2> i would essentially like each new drupal project to be a branch itself
[12:02] <George2> fullermd: 4 kitchens have one for core
[12:02] <SamB> it's just that CVS is so flaky -- why haven't they switched to SVN ?
[12:02] <George2> SamB: no one to update it
[12:03] <SamB> hmm?
[12:03] <fullermd> Well, *I* never switched to svn.  It exchanges CVS's braindamage for its own, which may or may not really be a win in a given case.
[12:03] <George2> what confused  me about git was clone, pull, fetch, checkout etc
[12:03] <SamB> fullermd: well, I prefer atomic braindamage
[12:03] <SamB> which brain damage of SVN's were you referring to, anyway?
[12:04] <fullermd> The bizarre fluidity of its pseudo-branchiness, for one.
[12:04] <SamB> oh, yeah, I do hate that
[12:04] <fullermd> More abstractly, CVS's intense dainbramage has the advantage of being well known and plumbed, so Everybody (FSVO) knows how to deal with it and what actions to avoid.
[12:05] <SamB> it works fine if you adhere to the trunk/branches/tags convention though
[12:05] <SamB> though the fact that such "tags" are mutable is lamentable :-(
[12:05] <fullermd> And it's there and running.  Moving to any other VCS is a moderately involved undertaking, so if you're gonna go through it anyway, might as well go to a good choice instead  ;)
[12:05] <fullermd> Anyway.
[12:06] <SamB> well, yeah, I guess
[12:06] <SamB> but staying with CVS?
[12:06] <SamB> that's harder to imagine
[12:06] <fullermd> Drupal was at that time in the past at least fairly actively considering moving to bzr.
[12:06] <George2> ok, so i think i have dir structured now - thanks!
[12:06] <fullermd> But the last I heard of that was, like, 3.5 years ago or something.
[12:07] <fullermd> George2: I would definitely take the stance that you'll set it up to experiment with, with the expectation of throwing your first organization away at some point.
[12:07] <George2> however, what about minor updates? i'd like to have a browsable dir structure like drupal / drupal-6 / drupal-6--9 etc
[12:07] <SamB> so does anyone have any idea about the conflicts in http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2298 ?
[12:08] <George2> fullermd: yeah, that's the painful part :(
[12:08] <fullermd> http://drupal.org/node/45368
[12:09] <fullermd> That's only ~ a year old, so it may still be being kept up.
[12:09] <fullermd> It points at a LP import, so I'd guess so.
[12:10] <George2> ohhh
[12:10] <fullermd> SamB: It looks like a giant mess.  Smells like a merge of a near-exact copy of a tree you had sitting around, un-add'd in the dir before you merged.
[12:10] <George2> i think i understand!
[12:10] <SamB> fullermd: actually I tried to use "bzr upgrade" in an svn checkout
[12:10] <fullermd> ...
[12:11] <fullermd> Oh.  In that case I suggest "sobering up"   :p
[12:11] <SamB> it half worked: https://bugs.launchpad.net/bzr/+bug/340854
[12:11] <SamB> then I ran "bzr reconfigure --checkout"
[12:11] <SamB> and that actually worked
[12:11] <George2> i *could* have a shared-repo for say a drupal-core branch and for each major and  minor version, just tag appropriately
[12:12] <George2> bzr is just so damned difficult to type :/
[12:14] <fullermd> That's just 'cuz it's not trained into your fingers yet.
[12:14] <fullermd> Once it is, you'll find that 'bzr' is impossible to type.
[12:14] <fullermd> ...
[12:15] <fullermd> Dangit.  'bar' is impossible to type.
[12:15] <fullermd> See what I mean?
[12:16] <pigmej> fullermd: For me it's easy to type ;d
[12:16] <pigmej> 3 fingers and "done" :d
[12:17] <pigmej> easier than svn
[12:18] <George2> svn and cvs are easy
[12:18] <George2> git is nice
[12:19] <pigmej> hmm
[12:19] <George2> let's propose bzr changes its name :)
[12:19] <pigmej> cvs is harder to write becouse of you need to change key on the same finger
[12:19] <pigmej> bzr is to type with 3 different fingers, svn too
[12:19] <pigmej> git too
[12:19] <pigmej> Ehh i forgot, I have other layout ;d
[12:19] <fullermd> cvs is 3 different fingers for me...
[12:20] <fullermd> Actually, the only vcs that isn't that comes readily to mind is cdv.  darcs too, I guess.
[12:21] <fullermd> Maybe baz if anybody still uses it.  But people left in that world presumably all use tla.
[12:22] <Peng_> I think "hg" wins at typability. :P
[12:22] <pigmej> Peng_: right ;d
[12:23] <fullermd> Actually, it seems a bit lower for me.  It means yanking both hands away from home.
[12:23] <pigmej> so let's make an "a" vcs
[12:23] <pigmej> ;d
[12:23] <fullermd> bzr is a quick rock with one hand.
[12:23] <fullermd> git is more sensitive to timing between hands too.
[12:24] <Peng_> How do Dvorak keyboards change this? :D
[12:24] <fullermd> On the other hand, RCS wins because you don't even need to type the VCS's name before the command.
[12:25] <pigmej> do you use qwerty layout ?
[12:27] <George2> non-qwerty sucks for programmers
[12:27] <pigmej> George2: I use colemak
[12:27] <pigmej> ;d
[12:28] <pigmej> for about 7 months and I'm really impressed
[12:28] <pigmej> and happy
[12:28] <nevans> my new years resolution was to learn colemak by the end of 2009... haven't made any real progress yet...
[12:28] <pigmej> before colemak I used naturally qwerty ;d
[12:29] <pigmej> nevans: First month was terrible...
[12:29] <pigmej> First days was a #$%^&*
[12:29] <pigmej> but now I'm very very happy :)
[12:29] <nevans> pigmej: did you just switch to it for everything all at once, or ease yourself into it (an hour or two a day)?
[12:29] <fullermd> Eek, what is colemak doing stealing my Ctrl key for an extra backspace?   :p
[12:29] <pigmej> nevans: everything
[12:30] <nevans> fullermd: I thought it did that with CapsLk, not Ctrl
[12:30] <pigmej> fullermd: backspace is moved to capslock
[12:30] <nevans> to CapsLk, I say good riddance.
[12:30] <pigmej> and that's one of the best things in colemak
[12:30] <fullermd> Only for silly people who didn't do away with their capslock already and make it a Ctrl.
[12:30] <fullermd> It looks like it would suck for moving around in vi though.  So not much point...
[12:30] <nevans> I've mapped it to Esc in the past, but that always winds up hurting me when I start vimming at someone else's computer.  ;)
[12:31] <pigmej> fullermd: it's optional, there are coleak layout's without that modification
[12:31] <George2> colemak?
[12:31] <pigmej> btw nevans as I sad, I switched to colemak completly.
[12:31] <pigmej> all hours on colemak
[12:32] <pigmej> every single letter...
[12:32] <pigmej> and the beginning was a little bit hard
[12:32] <pigmej> now it's very very good ;d
[12:32] <George2> i thought qwerty was designed to slow typists down
[12:32] <pigmej> George2: right ;)
[12:33] <fullermd> Not exactly, no...
[12:33] <George2> why is it called colemak?
[12:33] <pigmej> George2: becouse qwfpgj isn't good name ;d
[12:33] <pigmej> because*
[12:33] <nevans> http://colemak.com/FAQ#Why_is_it_called_Colemak.3F
[12:33] <George2> and where's caps lock?
[12:34] <pigmej> there is no capslock George2 ;d
[12:34] <George2> i need a keyboard that has a $ key without pressing shift
[12:34] <pigmej> why ?
[12:34] <pigmej> php ?
[12:34] <George2> what about apostrophe?
[12:34] <George2> yeah php
[12:34] <pigmej> George2: the changes to qwerty are not so big
[12:34] <luks> I wonder if typing speed is really the bottleneck for you in programming
[12:35] <luks> it surely isn't for me
[12:35] <pigmej> but very very important
[12:35] <George2> luks, not so much speed, but pressing shift for such an essential char is a pain, same with underscore
[12:35] <George2> $_GET['foo'] = ugh to type
[12:35] <pigmej> luks: less "distance" for fingers it's better
[12:36] <luks> that's where you problems start, don't use $_GET :)
[12:36] <pigmej> for our fingers ;d
[12:36] <George2> an ampersand key would be nice too
[12:36] <George2> until that day, i'm not switching!
[12:37] <luks> pigmej: I personally spend less time typing than I do with other tasks
[12:37] <George2> can i see a list of branches available ala git?
[12:37] <fullermd> $_GET is easy, you just hold down shift the whole time   :p
[12:38] <fullermd> And the _ is the only other char with the right hand, so that pinkie just takes a little nap on shift.
[12:39] <pigmej> luks: I'm typing a lot...
[12:39] <pigmej> my keyboards ( always MS natural ergo 4000 ) lives about 6-8 months ;d
[12:40] <luks> must be very boring programming :)
[12:40] <fullermd> Sunday is my keyboard's 18th birthday   :p
[12:40] <pigmej> luks: programming is my hobby ;)
[12:40] <pigmej> not a work :)
[12:40] <luks> even worse then :)
[12:41]  * fullermd would treat a keyboard with a 6 month lifespan with explosives...
[12:41] <luks> my keyboards last for about a year, but for different reasons
[12:42] <George2> i <3 my ms media keyboard, really comfy and right amount of firmness
[12:42] <George2> unfortunately i don't have it here :(
[12:43]  * fullermd ain't budging from his Model M.
[12:48] <George2> is it not possible to switch to a tag directly? i have to use the revision number associated with that tag?
[12:49] <fullermd> You can only switch to branches.
[12:49] <George2> oh
[12:56] <LeoNerd> A tag is a single static snapshot in time.
[12:56] <LeoNerd> You could checkout, or export it.
[12:58] <George2> no namespace registered for string:u'MY_TAG'
[12:59] <Peng_> George2: "tag:MY_TAG"?
[12:59] <George2> ohh
[12:59] <George2> heh, file exists .... .bzr
[12:59] <George2> trying to checkout in same dir
[13:06] <George2> bzr forces a new branch to be a new dir doesn't it?
[13:12] <Peng_> George2: Yes.
[13:12] <Peng_> George2: There's some work being done on making that...not the case.
[13:12] <George2> that's what i really like about git
[13:12] <George2> making it so easy to be able to switch between tags and branches with a simple checkout
[13:18] <awilkins> Model M 4tw
[13:21] <Peng_> Earplugs 4tw
[13:21] <Peng_> :P
[13:32] <George2> can i get a one-way checkout? ie. if i checkout out a branch, i want to be able to delete files and hack at it, and then start a new project with it, but for it to still update if the parent updates
[13:33] <Peng_> Isn't that what a branch is for?
[13:35]  * Chipdancer waves to jml and wonders where poolie is
[13:36] <George2> ,hh
[13:42] <George2> uh oh. how do i pull from two branches into one?
[13:43] <ronny> George2: if they diverged, merge
[13:43] <George2> ronny - they're separate branches with no common ancestor
[13:46] <hmeland> IIRC, in branch1, you can do "bzr merge -r 0.. /path/to/branch2" to merge the two branches' histories.
[13:50] <derekS>  hey guys. Is there a way to validate my local repository?
[13:52] <Peng_> derekS: "bzr check"?
[13:55] <George2> omg, there has to be an easier way!
[14:01] <George2> does this sound sane? i create a dir for drupal core files. i commit an empty dir. i branch from that and make a branch for modules. i put the core files in the core branch and commit. i put modules in the modules branch and commit. when i start a new project. i branch from core, and then merge in the modules branch
[14:03] <derekS> Peng_: thanks!
[14:05] <devilsadvocate> George2, that does not sound sane :P
[14:06] <Peng_> derekS: BTW, some unimportant things like inconsistent parents can be fixed with "bzr reconcile", but you don't need to bother.
[14:06] <George2> devilsadvocate: well how else can i merge two branches together that have no common base?
[14:06] <George2> i want to make a project that pulls from two branches. that sounds sensible in itself right. that has to happen all the time?
[14:06] <devilsadvocate> George2, what hmeland said?
[14:06] <LarstiQ> George2: you could use the scmproj plugin
[14:06]  * George2 scrolls up
[14:07] <George2> hmeland: but the histories shouldn't be merged as they're  unrelated
[14:07] <LarstiQ> George2: then merge/pull is not the operation you are looking for
[14:08] <George2> so what is then?
[14:08] <George2> i can't checkout as .bzr already exists
[14:08] <derekS> Peng_: i just want to do a validate, time isn't an issue, so you would reccomend doing a check then reconcile
[14:08] <derekS> just for the sake of doing it?
[14:09] <Peng_> derekS: I dunno. reconcile is redundant if there's nothing wrong.
[14:09] <LarstiQ> George2: I haven't scrolled back and analyzed your problem, but in passing it sounds like what scmproj would help with.
[14:10] <devilsadvocate> George2, if you dont want the histories then why do you want to merge? as in, you could just make a folder and add the files
[14:11] <George2> devilsadvocate: i'd like to have a 1-way relationship where if the files update in teh original branch, i can easily update in this branch
[14:12] <devilsadvocate> George2, typically, if two things are separate, you should probably continue to keep them separate.
[14:12] <devilsadvocate> IMO
[14:12] <George2> that' not possible. cms / modules for cms
[14:12] <George2> they have to be combined for a site project
[14:13] <devilsadvocate> hm, your modules folder is within your cms folder
[14:13] <George2> yep
[14:13] <devilsadvocate> i you can remove individual files from version control. how about you add a single file, a symlink to the modules folder. dont add that to the repo. job done.
[14:13] <LarstiQ> George2: I repeat, http://launchpad.net/bzr-scmproj
[14:14] <LarstiQ> or devilsadvocate's advice if that's enough for you
[14:14] <George2> LarstiQ: i'm looking at it now
[14:14]  * LarstiQ trots off to work
[14:14] <LarstiQ> George2: good luck
[14:14] <George2> thanks
[14:15] <George2> devilsadvocate: yeah, i've thought about symlinking, which would be a nice solution, and is something i'm using atm without version control. however, and export wouldn't resolve those symlinks right?
[14:16] <devilsadvocate> George2, probably not, especially if they arent version controlled.
[14:16] <devilsadvocate> im not sure
[14:20] <George2> wow
[14:21] <George2> devilsadvocate: i've put a file in a test repos anad commited, and in another separate branch added a symlink, and export resolves it ;)
[14:21] <devilsadvocate> nice :)
[14:21] <George2> as i'm working on a local machine only, that sorts it :)
[14:21] <George2> that's genius!
[14:22] <devilsadvocate> if your ftp or whatever you use to expose the bzr (if you do expose the bzr) is configures to follow symlinks, it will works remotely as well, then
[14:22] <George2> yep
[14:23] <George2> but this is just for a local machine atm, so this is perfect!
[14:34] <derekS> Peng_: thanks :)
[14:36] <Peng_> derekS: You shouldn't need to run "bzr reconcile" more than once, so I wouldn't add it to your cronjob or whatever.
[14:38] <ronny> jelmer: aware of a gentoo overlay for subvertpy/bzr-svn?
[14:48] <jelmer> ronny, I think the gentoo bzr overlay has both
[14:48] <jelmer> ronny, http://launchpad.net/bzr-gentoo-overlay IIRC
[14:55] <derekS> Peng_: i wasn't planning on it. i want to push my directory to the parent server, just wanted to make sure it was all good
[14:56] <thecookie> Hmm. This is not really a bzr question, but.. I'm using eclipse. What is the smoothest way to work with a new branch? Seems a bit sucky to create a new project each time you want to work with a new branch.. and preparing it with the config files and such
[14:57] <LarstiQ> thecookie: `bzr switch`
[14:59] <thecookie> I see. Switch with my main branch? (Not sure it's called that but the branch I first checked out called trunk)
[15:00] <derekS> anyone knwo of a decent ide for windows that does python and perl that natively supports bzr? Komodo is too expensive but fits the bill. Eclipse is a beast...
[15:01] <ronny> jelmer: it does, thanks
[15:08] <thecookie> Hmm. So, locally I would have a mirror of the master server, a local working tree and a new branch?
[15:10] <devilsadvocate> thecookie, bzr bind?
[15:13] <LarstiQ> devilsadvocate: no, just a lightweight checkout and switch
[15:14] <thecookie> What should the master with the main branch host? A branch? Working tree? Checkout?
[15:14] <thecookie> Locally I followed http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style
[15:16] <cyberix> I'm trying to use "bzr send<EMAIL_ADDRESS>[15:16] <cyberix> Evolution opens up, but tells me...
[15:16] <cyberix> "You cannot attach the file `%2Ftmp%2Fbzr-mail-GPry9l%2Fmsk-32.patch' to this message."
[15:16] <cyberix> "Cannot attach file %2Ftmp%2Fbzr-mail-GPry9l%2Fmsk-32.patch: No such file or directory"
[15:17] <cyberix> Is this a known problem?
[15:17] <LarstiQ> cyberix: not that I know of, does the un-urlencoded path exist?
[15:17] <cyberix> Also when I pass the error, I notice that the email address is prefixed with ///
[15:17] <LarstiQ> cyberix: that, however, is known.
[15:17] <cyberix> LarstiQ: Yes it does
[15:17]  * LarstiQ looks up the bug number
[15:18] <cyberix> cyberix@eval:/tmp/msk$ du -b /tmp/bzr-mail-GPry9l/msk-32.patch
[15:18] <cyberix> 1638	/tmp/bzr-mail-GPry9l/msk-32.patch
[15:18] <LarstiQ> bug 291847 I believe
[15:27] <cyberix> I filed a bug
[15:27] <cyberix> https://bugs.launchpad.net/bzr/+bug/341182
[15:29] <LarstiQ> cyberix: I suppose send -o and attaching by hand works though?
[15:30] <cyberix> Last time it failed I just corrected the email address and attached the file from tmp by hand
[15:30] <cyberix> and the patch was applied
[15:30] <LarstiQ> good
[15:31] <cyberix> and it worked fine
[15:31] <cyberix> should I still try using -o?
[15:31] <LarstiQ> cyberix: nah, if it worked then, I trust it works now
[15:32] <cyberix> ok
[15:55] <kfogel> heh: lots of people seeing this error with recent dev sources?
[15:55] <kfogel> bzr: ERROR: exceptions.AttributeError: 'Serializer_v5' object has no attribute '_init_inventory_with_root'
[16:02] <kfogel> Anyone understand what's going on here: http://paste.lisp.org/display/76830
[16:02] <kfogel> ?
[16:02] <kfogel> kiko__: ^^ :-)
[16:03] <luks> you probably want svn up
[16:03] <luks> er
[16:03] <luks> bzr up
[16:03] <luks> :)
[16:05] <kfogel> luks: I guess what's confusing me is: I've been using that bound branch as a local mirror of trunk for ages now, and all I've ever had to do is 'bzr pull'.  That has always updated my working tree, and afterwards I just do 'sudo python setup.py install' if I want to install the latest bzr dev sources.
[16:05] <kfogel> luks: So why all of a sudden is it not updating the working tree?
[16:06] <LarstiQ> kfogel: you haven't reverted it to a non head revision per chance?
[16:06] <kfogel> LarstiQ: not to my knowledge.  Would there be some way for me to tell if I've done that?
[16:10] <luks> brw, the result of bzr info -v doesn't seem to indicate a bound branch
[16:10] <luks> *btw
[16:11] <luks> you would see 'checkout of branch: http://bazaar-vcs.org/bzr/bzr.dev/'
[16:11] <thecookie> So, even tho the main branch server didn't do an update, other people can do a pull from it after one has done a push towards it?
[16:11] <kfogel> luks: hmrmrm.
[16:11] <kfogel> cat .bzr/branch/branch.conf
[16:11] <kfogel> parent_location = http://bazaar-vcs.org/bzr/bzr.dev/
[16:11] <luks> that's parent location, not the bound branch location
[16:12] <kfogel> luks: I may be using the term "bound branch" incorrectly.  I *also* did a 'bzr bind' to that URL when I edited branch.conf.
[16:12] <kfogel> (This was all more than months ago.)
[16:12] <kfogel> s/more than//
[16:13] <luks> kfogel: well, what you have is a standalone branch, not a bound branch
[16:13] <kfogel> luks: okay, thanks.  Any ideas why it would have been working (that is, updating the working files whenever I did bzr pull) before now?
[16:14] <luks> do you want to use a standalone branch or a bound branch?
[16:14] <kfogel> luks: I guess I'll go re-read the user's guide and make sure I understand those terms before answering!
[16:14] <kfogel> :-)
[16:14] <kfogel> luks: I can tell you the behavior I want, maybe that would help?
[16:14] <luks> kfogel: sure
[16:17] <kfogel> luks: I'm trying to maintain a pure mirror of http://bazaar-vcs.org/bzr/bzr.dev/ -- locally, I call it bzr.dev-trunk.  The only way changes ever get into bzr.dev-trunk is by me doing 'bzr pull', which would update both the branch and the working tree.  Periodically, I make further local branches of bzr.dev-trunk when I want to actually do development, but I never push changes back into bzr.dev-trunk from them, nor do I do 'bzr merge' in bzr.dev-trunk.
[16:17] <kfogel>   It is intended to always mirror a current or past state of the bzr dev trunk, nothing more.
[16:17] <kfogel> luks: this seemed to work for a while; today apparently it has stopped.
[16:17] <luks> by making local changes you mean 'edit && commit' or just 'edit'?
[16:18] <luks> because commit wouldn't be possible in such a bound branch
[16:18] <kfogel> luks: both
[16:18] <kfogel> luks: AFAIK, I've never done a commit in there.
[16:19] <luks> oh, I misread a part of it
[16:19] <rocky> jelmer: hey, why is it that when i install bzr-rebase (latest on bzr 1.13rc1) and do "bzr plugins" that rebase doesn't display ?
[16:19] <rocky> but "bzr rebase" does actually work
[16:19] <kfogel> luks: I've occasionally edited a file and then done 'bzr revert file' (I think -- not sure I've done even that)
[16:19] <luks> kfogel: well, what I'd do it 'bzr up' in the current bzr.dev mirror
[16:19] <luks> kfogel: then 'bzr bind http://bazaar-vcs.org/bzr/bzr.dev/'
[16:20] <kfogel> luks: hunh.  Okay.  Thanks
[16:20] <luks> kfogel: and then *only* 'bzr up' whenever you want to update from the remote location
[16:20] <kfogel> luks: ???
[16:20] <kfogel> Sigh.  I got a different answer from knowledgeable devs on the list when I started this process.
[16:20] <kfogel> So you're saying 'bzr up' where I used to do 'bzr pull'?
[16:21] <luks> kfogel: 'bzr up' is used in a checkout (bound branch), 'bzr pull' is used in a standalone branch
[16:21] <luks> bound branch basically means you are working with the remote branch using the local working tree
[16:21] <kfogel> luks: is "standalone branch" synonymous with "standalone tree" ?
[16:21] <luks> um, I don't know what "standalone tree" is
[16:21] <kfogel> luks: "checkout" and "bound branch" are exactly synonymous?
[16:22] <luks> yes
[16:22] <kfogel> luks: "standalone tree" is a phrase in the Users Guide (where I've been reading while we talk)
[16:22] <luks> maybe they mean lightweight checkout
[16:22] <luks> where no history is stored on the local side
[16:22] <luks> but that's not very useful for you
[16:22] <kfogel> luks: note that the parent directory of all this is a repository.
[16:23] <jelmer> rocky, no idea, sorry
[16:23] <kfogel> I did bzr init-repo, then set up bzr.dev-trunk, and then the other branches.
[16:23] <kfogel> luks: don't know if that's relevant, but thought I'd mention it.
[16:23] <jelmer> rocky, the listing of plugins is up to bzr itself not to the individual plugins
[16:23] <luks> kfogel: according to your bzr info, there is no shared repository
[16:23] <kfogel> luks: !!! ???
[16:23] <kfogel> luks: dang it, I was so careful to set this up.
[16:23]  * kfogel sobs
[16:23] <kfogel> I pasted transcripts on the list, I...
[16:23] <kfogel> Okay.
[16:24] <kfogel> Let me get calm :-).
[16:24] <luks> kfogel: run bzr info in the parent directory
[16:24] <luks> and pastebin that
[16:24] <kfogel> luks: sure, one sec
[16:25] <kfogel> luks: http://paste.lisp.org/display/76835
[16:26]  * LarstiQ blinks
[16:26] <luks> that another completely standalone branch :)
[16:27] <luks> wait a sec, let me write something down for you
[16:27] <LarstiQ> kfogel: you also have a ~/src/bzr/bzr-repo ?
[16:27] <kfogel> LarstiQ: hmmmm
[16:27] <LarstiQ> kfogel: it almost looks like ~/src/bzr is the result of `bzr init` instead of `bzr init-repo`
[16:28] <kfogel> luks: LarstiQ may have caught a truly dumb braino here, one sec
[16:28] <kfogel> luks: ignore all the above please
[16:28] <kfogel> luks: PEBK
[16:28] <kfogel> luks: PEBKAC
[16:28] <kfogel> sigh
[16:28] <luks> http://rafb.net/p/YR964W31.html this is what you want
[16:28] <kfogel> I know what happened now.  And it's simultaneously complicated and truly boring.  I'm going to fix the setup so this can't happen again.
[16:29] <kfogel> luks: thanks for your time
[16:29] <LarstiQ> kfogel: for later reference then, in the case of having a branch that doesn't use a shared repository above it, `bzr reconfigure --use-shared`
[16:29] <kfogel> LarstiQ: thank you
[16:29] <kfogel> luks, LarstiQ: I can move a shared repo directory around with no penalty, right?
[16:30] <LarstiQ> kfogel: yes, but
[16:30] <LarstiQ> kfogel: as long as you move all the contained branches with it
[16:30] <LarstiQ> kfogel: (so normal unix mv semantics on the repo dir would do that)
[16:30] <kfogel> LarstiQ: well, I'm just moving the entire repo dir from above, from its parent to its grandparent -- the branches inside will get moved along with it.
[16:30] <LarstiQ> kfogel: that's fine then
[16:30] <kfogel> LarstiQ: ah, okay, yeah, Unix mv
[16:31] <kfogel> luks: if we ever meet, you'll see me looking slightly embarrassed
[16:31] <luks> heh :)
[16:47] <kfogel> luks: so now I've moved everything around and I'm doing 'bzr pull' in $MY_BZR_SHARED_REPO/bzr.dev-trunk/, and it ran for 10 min with no output.  I hit C-c and now am rerunning with -v...
[17:21] <Kobaz> how would i move a file from one branch to another, preserving it's history
[17:57] <kfogel> luks: somewhat shy to ask another question, after my last round, but: have you seen this error lately?
[17:57] <kfogel> http://paste.lisp.org/display/76845
[18:04] <LarstiQ> kfogel: I haven't
[18:05] <LarstiQ> kfogel: it seems like you are using an older format though
[18:05]  * LarstiQ tries to reproduce with that information
[18:07] <kfogel> LarstiQ: (phone)
[18:07] <kfogel> thx
[18:15] <kfogel> LarstiQ: I'm re-initializing the shared repo with --1.9 and re-branching trunk
[18:22] <LarstiQ> kfogel: line 37 of xml5.py looks very different here
[18:23] <kfogel> LarstiQ: thx (on phone, will look in detail when off)
[18:23] <LarstiQ> kfogel: I'm fine with carrying on conversations over multiple days, no hurry :)
[18:43] <luks> kfogel: initializing a repository with a different format than the upstream branch is only going to cause slowness
[18:43] <kfogel> luks: thx
[18:43] <luks> kfogel: because it has to transcode every time it needs to access the remote branch
[18:43] <kfogel> luks: ah
[18:44] <kfogel> luks: (on phone)
[18:44] <luks> I think bzr.dev is still in --pack-0.92, which is the default format
[18:45] <luks> hm, I'm wrong, it's 1.9 now
[18:48] <LarstiQ> yeah, the switch happened a little while ago
[19:39]  * emmajane waves.
[20:00] <marianom> hi everyone. I'm currently running bzr 1.3.1 in a CentOS server. Anyone know where I can find an up2date rpm?
[20:02] <marianom> I'm checking http://bazaar-vcs.org/DistroDownloads, will try epel testing
[20:11] <marianom> ummm... epel-testing has the same package that epel... too bad
[20:12] <GPHemsley> Can I get Loggerhead help here, or no?
[20:12] <mwhudson> GPHemsley: sure
[20:13] <GPHemsley> mwhudson: How can I install it on a Mac?
[20:13] <GPHemsley> I've used port to install py25-paste and py25-pastedeploy, but I'm stilling getting an error
[20:13] <GPHemsley> ImportError: No module named paste
[20:14] <mwhudson> you don't really need to install loggerhead to get it to work
[20:14] <mwhudson> GPHemsley: um, are you running loggerhead with the same python you installed the dependencies for?
[20:15] <mwhudson> GPHemsley: try "import paste" at a python prompt
[20:15] <GPHemsley> oh, hmm
[20:15] <GPHemsley> maybe not
[20:15] <GPHemsley> I suppose that would do it
[20:15] <GPHemsley> any idea how I can connect the two?
[20:16] <mwhudson> GPHemsley: something like /opt/bin/python serve-branches
[20:17] <GPHemsley> DNE
[20:20] <marianom> sorry to bother again guys. but I have this commit (single file) and is taking, well, more than an hour.
[20:20] <marianom> it's stuck at "Uploading data to master branch - Stage:Finishing pack 5/5"
[20:20] <marianom> if I ^C it, I have to log in the server and break-lock to release it.
[20:21] <marianom> what can be happening?
[20:22] <emma> Hey guys. I'm doing some independent research, I just wanted to ask a history of FOSS question.
[20:22] <emma> Why was bzr made when git already existed and (i've been told) git does everything bzr does.
[20:23] <emma> some people have also claimed that git is faster, but I'm not claiming that, if that were true then it is even more mysterious though.
[20:23] <LeoNerd> Why anything?
[20:23] <LeoNerd> Specifically.. what makes you think it came second?
[20:23] <LeoNerd> Furthremore.. why have just one?
[20:23] <emma> I was just told by several generally knowledgable geeks that git was made first.
[20:24] <emma> if that's not true well then that is important to know too.
[20:24] <LeoNerd> Was it public enough? Usable enough?
[20:24] <mwhudson> bzr's lineage is definitely older than git
[20:24] <LeoNerd> bzr has a lot of history from bazaar, which is a fork of tla, which is an implementation of arch,...
[20:24] <LeoNerd> That's years older than git
[20:25] <emma> so git was by far not a new idea or something Linus came up with.
[20:25] <LeoNerd> These sorts of ideas have been milling around for aaaages
[20:25] <LeoNerd> bzr, git, hg, darcs, monotone... they're all reinventions of the same sort of idea
[20:25] <LeoNerd> Before them was perforce, svn... cvs... rcs..
[20:25] <LeoNerd> sccs... sourcesafe...
[20:26] <emma> Some people say that modern development of bzr didn't happen until around 2006
[20:26] <LeoNerd> Some people say all sorts of things.
[20:26] <mwhudson> emma: revision 1 in the bzr tree has the date 2005-03-09
[20:27] <mwhudson> emma: the first email about git was on 2005-04-07, i think
[20:27] <mwhudson> so it's not really clear to talk about "which came first"
[20:30] <lifeless> LeoNerd: bzr's commit history doesn't have anything from 'bazaar' or 'tla'; the heritage is purely conceptual
[20:30] <lifeless> marianom: is there anything in ~/.bzr.log? What bzr version?
[20:32] <thumper> mwhudson: surely that is for bzr not baz right?
[20:33] <luks> thumper: that's bzr, and it's date since it was self-hosting, not since it existed
[20:33] <thumper> ah, that makes sense
[20:33] <luks> the commit message says "import from baz patch-364"
[20:35] <emma> look what I found -- http://bazaar-vcs.org/BzrVsGit
[20:35] <emma> is that bazaar the same thing as bzr ?
[20:36] <thumper> emma: Bazaar is the long name, bzr is the command
[20:36] <lifeless> luks: thats a migration of bzr's commits, while it was bootstrapping it was versioned in a baz tree
[20:36] <emma> okay but it is the same app, i wasn't sure if bzr was a spin off of Bazaar.
[20:36] <thumper> emma: Way back, Bazaar related to baz, and bazaar-ng was bzr (since you are asking about history)
[20:37] <thumper> emma: baz was depricated and bzr took the reigns
[20:37] <lifeless> emma: in terms of debian packages, 'bazaar' was 'baz'
[20:37] <emma> wow it's very complicated.
[20:37] <thumper> emma: there is a lot of history
[20:38] <emma> in your opinion if someone did not know either git or bzr, and then someone learned one of them, would they be relatively further along to know the other much more easily?
[20:39] <Peng_> Oh, the original baz history wasn't imported into bzr?
[20:39] <Peng_> emma: Yes.
[20:39] <Peng_> (That's a helpful answer, eh?)
[20:39] <emma> it's a rare answer but a cool one :)
[20:40] <luks> but just learning basics of one would not help you much with the other one
[20:40] <luks> because they *look* different
[20:41] <lifeless> Peng_: the history for 'baz' has been converted into a bzr tree, but its not part of the 'bzr' history :)
[20:41] <emma> well i have some personal investment in ubuntu so I will probably go with bzr.
[20:41] <lifeless> Peng_: we need better adjectvies for this discussion :P
[20:41] <Peng_> emma: Good idea, but I'm ever so slightly biased. ;P
[20:41] <luks> Peng_: I think he meant "bzr from baz", not baz itself
[20:41] <luks> er, lifeless
[20:42] <marianom> lifeless: thanks for answering. I'm getting: http://paste.ubuntu.com/129926/
[20:42] <Peng_> I don't know. What are we talking about?
[20:42] <Peng_> lifeless: That's a shame. Why wasn't it converted at the time? Doesn't everyone want to write a complicated converter instead of doing real work on their new project? :D
[20:42] <lifeless> 214.312  Auto-packing repository <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0xa53138c>, which has 14 pack files, containing 922 revisions. Packing 9 files into 1 affecting 22 revisions
[20:42] <lifeless> marianom: ^ thats the key thing, its doing an autopack
[20:43] <lifeless> marianom: what bzr version do you have?
[20:43] <marianom> lifeless: the server is Bazaar (bzr) 1.3.1 and my os has Bazaar (bzr) 1.12.
[20:43] <lifeless> Peng_: well its a completely different code base, there is no benefit to converting
[20:43] <marianom> the thing is that it already packed in a previous commit
[20:43] <marianom> one I did a few minutes earlier
[20:44] <lifeless> marianom: so, two separate things; if you upgrade the server to bzr 1.10 (I think thats the needed version, might be 1.11), it will do the autopack on the server which is much faster if you're not on a LAN
[20:45] <marianom> lifeless: ok. I was trying to find a rpm up2date in epel-testing to no avail (centos server here). it seems I will need to grab it from source
[20:46] <marianom> I hope I can remove current bzr with yum without affecting the branches
[20:46] <emma> Why does bzr use branch numbers. Someone I was talking to said that makes no sense in a distributed version control
[20:47] <lifeless> marianom: secondly, each commit is a 'pack', an autopack occurs every 10 commitsand prevents the number of packs getting too big (but it doesn't pack everything, so its generally very fast)
[20:49] <lifeless> emma: do you mean revnos ?
[20:50] <emma> lifeless: yeah the person I was talking to told me this, "revision numbers are problematic because: you start  with A at 1, branch it to A', code new features so that A' is at r10,  and backport a fix to A so it becomes r11. now, which branch has the  newer version?
[20:50] <emma> "
[20:51] <lifeless> emma: well neither, because they aren't fully merged :)
[20:53] <lifeless> emma: revno's don't tell you stuff about one branch relative to another, but thats not why we use them anyhow; we use them because they are usually nicer to work with and they are useful within a branch
[20:56] <kiko__> emma, git is definitely newer than bzr.
[20:56] <kiko__> emma, it was started by linus when the whole bk debacle happened
[20:56] <kiko__> it's all over kernelnotes
[20:57] <emma> lifeless:  what happens if you have two branches with the same revision
[20:57] <emma>                   numbers in them, but different commits, and try to merge them?
[20:57] <emma> oops im sorry
[20:57] <kiko> emma, they are different branches -- they will merge just fine.
[20:58] <emma> kiko: but what do you do with the revision numbers in that case?
[20:58] <kiko> emma, the merge will be a new commit wherever you are merging into.
[20:58] <lifeless> emma: the revnos are a ui layer, they don't affect the core system
[20:59] <lifeless> emma: in a given branch you know that '10' came before '11', which is kinda useful :)
[21:00] <thecookie> You push/pull between branches, and commit/update between.. working trees?
[21:00] <thecookie> Not sure about the term.
[21:01] <lifeless> thecookie: yup, spot on
[21:01] <lifeless> thecookie: merge goes from a branch to a working tree
[21:04] <thecookie> Great, starting to get a hang of it I think.
[21:09] <kfogel> lifeless: so revision numbers are essentially sequence numbers along a branch?
[21:09] <kfogel> (i.e., meaningless without the context of the branch to give them meaning?)
[21:09] <lifeless> kfogel: yes.
[21:10] <kfogel> lifeless: that's what I thought, but it never hurts to sanity check.  Thanks.
[21:10] <lifeless> 1234 in trunk is a useful statement
[21:10] <lifeless> 1234 isn't
[21:11] <kfogel> hmmm
[21:11] <kfogel> bzr nightly builds are via PPA only?
[21:13] <lifeless> kfogel: I think so
[21:13] <kfogel> lifeless: mrmrm.  Will ask on list; would be great (and probably just as easy) if they were also in source .tgz.
[21:19] <Necoro> if I have a lightweight checkout - and I want to export it ... why does it (with 0.12) take quite some time? - if (especially if the co is up2date) it could more or less simply to a "cp" ?
[21:19] <Necoro> with "quite some time" I mean: longer than creating a complete new checkout
[21:20] <lifeless> Necoro: its copying from the server
[21:20] <Necoro> why? - if it notices, that the co is unchanged and up2date, it could do a simple copy
[21:21] <thecookie> What is the current recommended way of duplicating the svn external feature?
[21:22] <lifeless> Necoro: well, the code as written just pulls from the repository; it makes it very small and clean; you are right that we we could add a check in the working tree when there is a working tree to copy content from it
[21:23] <lifeless> Necoro: please do file a bug that we don't take advantage of the local data in this case
[21:23] <lifeless> thecookie: config-manager, which is a bit clumsy but works, or I think bialix (Alexander Belchenko) is working on a GUI doing a very similar thing
[21:24] <Necoro> lifeless: ok - not now but later on
[21:24] <thecookie> Alright, I'll check those out
[21:25] <LarstiQ> thecookie: bialix's project is http://launchpad.net/bzr-scmproj
[21:27] <thecookie> Thanks :)
[21:28] <thecookie> You juse check out those plugin rather than using the donwload button from there?
[21:28] <thecookie> plugins*
[21:28] <mwhudson> kfogel: i guess you can just wget the orig.tgz from ppa.launchpad.net :)
[21:30] <LarstiQ> thecookie: yeah, cd ~/.bazaar/plugins ; bzr branch lp:bzr-scmproj scmproj; bzr plugins | grep scmproj
[21:31] <thecookie> Sweety
[21:31] <thecookie> Heh. -y ;P
[21:31] <mwhudson> kfogel: eg http://ppa.launchpad.net/bzr-nightly-ppa/ppa/ubuntu/pool/main/b/bzr/bzr_1.13~bzr8.10-4098-1.tar.gz
[21:31] <LarstiQ> mwhudson: which date is that for?
[21:32] <mwhudson> well, only the latest will be present i guess
[21:33] <LarstiQ> ah
[21:34] <LarstiQ> kfogel: did the fresh branching get rid of the xml5 serializer error?
[21:35] <thecookie> Seems I need a newer version of bzr to do that. Is there a .deb repo somehwere?
[21:35] <thecookie> Or maybe I just need a format plugin or something?
[21:36] <thecookie> bzr: ERROR: Unknown repository format: 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n'
[21:37] <lifeless> http://bazaar-vcs.org/Download
[21:37] <lifeless> (yes there is a deb repo)
[21:38] <LarstiQ> thecookie: you'd need bzr 1.9 or newer for that format
[21:39] <thecookie> using the default one in ubuntu now, 1.6.1
[21:39] <thecookie> I guess I'll get it updated
[21:41] <LarstiQ> thecookie: https://edge.launchpad.net/~bzr/+archive/ppa for ubuntu
[21:51] <mwhudson> so who do i have to hound to get my branch_implementations patch into 1.13 and my no-LockableFiles.__del__ into bzr.dev and 1.13?
[21:53] <lifeless> mwhudson: I'll land it in .dev for you; bob tanner is the 1.13 rm
[21:53] <lifeless> aka BasicOSX
[21:57] <mwhudson> lifeless: thanks, and ok\
[21:57] <mwhudson> BasicOSX: hi :)
[22:41] <LeoNerd> I don't suppose there's such a thing as bzr ununcommit  is there? ;)
[22:41] <LeoNerd> I accidentally uncommitted a commit
[22:41] <Peng_> LeoNerd: "uncommit" gave you the command to run to restore the revision.
[22:42] <LeoNerd> It does?
[22:42] <Peng_> LeoNerd: In recent versions, at least.
[22:42] <LeoNerd> Oh.. well.. no. I had local modifications before I started
[22:42] <LeoNerd> So now if I were to  ci   I'd commit a combination of the uncommitted and new changes
[22:43] <lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781
[22:43] <lifeless> LeoNerd: so, bzr pull . -r revid:<uncommittedid> will put it back
[22:43] <Peng_> LeoNerd: If you've lost the "uncommit" command, but it wasn't that long ago, you can grep ~/.bzr.log for "bzr pull . -r".
[22:43] <LeoNerd> Ah. But how do I know the revid?
[22:43] <lifeless> LeoNerd: if you don'tknow the revid, 'bzr heads --somethingoother' will tell you
[22:44] <LeoNerd> Ahyes
[22:44] <LeoNerd> I recall doing this last time
[22:44] <Peng_> Otherwise, yeah, "bzr heads". "--dead-only", I think.
[22:44] <LeoNerd> $ bzr heads --dead-only
[22:44] <LeoNerd> That got it
[22:45] <Peng_> :)
[22:45] <LeoNerd> Woo. Marvellous. Thanks guys.
[22:46] <lifeless> our pleasure
[22:48] <zanaga> is there a prebuilt plugin that allows me to bind a simple command to a local repository as a postcommit script?
[22:50] <lifeless> zanaga: I believe jelmer wrote a shell-hooks plugin, to allow running shell scripts on such events
[22:51] <zanaga> ah.. so it seems..
[22:51] <zanaga> thanks, that saves me a lot of typing
[23:03]  * mwhudson waves towards brisbane
[23:05] <lifeless> hi mwhudson
[23:05] <lifeless> so, loggerhead on chk; please test :)
[23:05] <mwhudson> um
[23:06] <mwhudson> i've actually forgotten how many things i'm doing _right now_ :)
[23:06] <mwhudson> but ok
[23:06] <lifeless> the sprint is only this week; its why I'm emphasising this
[23:07] <mwhudson> yes ok
[23:08] <lifeless> I have your no-LockableFiles.__del__ cycles queued
[23:08] <mwhudson> thanks
[23:11] <lifeless> mwhudson: I'm confused though, your branch has _LockCounter, but you say your bundle changes it; did you not push ?
[23:11] <mwhudson> um, no i probably didn't push
[23:12] <lifeless> no worries, I'll pull from bb
[23:14] <mwhudson> i have now, but whatever's easiest
[23:22] <mwhudson> lifeless: um, your bzr.dev.chk branch has a .bzr in it's .bzr
[23:22] <mwhudson> lifeless: you may wish to stab rsync?
[23:34] <lifeless> mwhudson: one of them will work :P
[23:37] <mwhudson> lifeless: nope
[23:38] <mwhudson> lifeless: https://pastebin.canonical.com/14842/
[23:39] <mwhudson> oh hm
[23:40] <mwhudson> and the other .bzr fails differently!
[23:40] <mwhudson> lifeless: http://pastebin.ubuntu.com/129985/
[23:49] <aedan> Hi There.
[23:50] <lifeless> mwhudson: I'll rsync it up again
[23:50] <aedan> I have two branches, one of my core PHP framework, the other is a branch of that framework will application specific files added.
[23:51] <aedan> Is it possible to sync a change to the framework made in the app branch back to the framework branch?
[23:53] <schmichael> is there a way to get syntax highlighting of `bzr diff` output (like hg) other than to run it through pygments: `bzr diff | pygmentize -l diff`
[23:53] <schmichael> if not i may try to work up a patch
[23:53] <bob2> is it possible to set BZR_REMOTE_PATH per-server?
[23:54] <bob2> setting it globally makes any authenticated lp access splode
[23:54] <bob2> aedan: not easily
[23:54] <bob2> schmichael: adding that to bzrtool's cdiff would be awesome
[23:54] <aedan> bob2: Hrmph.  Thanks for the reply though. :)
[23:54] <bob2> schmichael: unless what that does is the same as what cdiff already does
[23:55] <schmichael> bob2: ah, looks like it.  thanks
[23:55] <aedan> bob2: So in that instance, I'd be best off moving the file over manually?
[23:55] <bob2> aedan: no
[23:55] <aedan> bob2: oh?  What'd the best solution be?
[23:55] <lifeless> bob2: yes, ~/.locations.conf
[23:56] <lifeless> bob2: see the list today :)
[23:56] <bob2> aedan: I don't know
[23:56] <bob2> lifeless: oh, cheers
[23:56] <lifeless> so, I need to go from "foo.bar.baz" to foo.bar.baz, are there stoill no easy eays to do this?
[23:57] <bob2> in python code?
[23:58] <aedan> bob2: Is there perhaps an entirely different layout that'd make it easier?  Basically it's just that I have a framework and an app using the framework.
[23:58] <spiv> lifeless: twisted.python.reflect.namedAny("foo.bar.baz")  :P