[00:23] <fullermd> lifeless, jelmer: https://bugs.launchpad.net/bzr/+bug/1072513
[00:23] <fullermd> Sorry, the desc is long maze of twisty little passages, all subtly different   :|
[00:24] <fullermd> Urg, the online formatting robbed some of the whitespace that made it less unreadable too   :(
[00:27] <fullermd> My "favorite" part (aside from the existence in the first place, anyway) is how the more extra revs you remove, the more "proper" revs show up in the result.
[01:00] <mark06> hi, is it possible to add --fixes later to an specific commit, just like you can tag? also, the translated url (e.g. lp => http://launchpad...) is what goes on --fixes right? (that is, no chance to ever get "lp:" translated into something else)
[01:03] <fullermd> Pretty sure not.  Fixes is part of the commit.
[01:03] <fullermd> Whereas you don't add tags to a commit, you more add commits to a tag.
[01:04] <lifeless> mark06: the translation is controlled by config
[01:04] <lifeless> mark06: you can make --fixes lp:1234 become anything you want, but much better is to add your own mapping to your own bug tracker.
[01:04] <lifeless> mark06: e.g. --fixes twisted:1234 and have that resolve to the twisted trac instance.
[01:04] <lifeless> mark06: see the docs for info.
[01:06] <AfC> mark06: I had to do that once for GNOME's bug tracker, but then the Bazaar developers added gnome: to the built-in configuration for us. But it is eminently do-able to define your own mappings.
[01:13] <mark06> lifeless: I wanted to avoid the chance of it ever getting translated into something else, something like an on-the-fly macro translating tracker: into a raw url, or at least by allowing the branch to hold the mapping itself (and assigning it a higher priority in comparison to user or global configs)
[01:17] <jelmer> mark06: the branch always stores the full URL if you use --fixes, it never stores the shorthand
[01:26] <mark06> ah good!
[01:32]  * mark06 has evil plans to map rev: into e.g. http://bazaar.launchpad.net/~renatosilva/+junk/trf/revision
[02:33] <mark06> thanks all
[03:35] <Guest40826> Is this a suitable place to ask questions about Loggerhead?'
[03:40] <Guest40826> Or should I direct my question elsewhere?
[03:42] <spiv> Guest40826: this is a good place.
[03:42] <Guest40826> Alright, thanks.
[03:42] <Guest40826> I've been trying to configure Loggerhead
[03:42] <spiv> Guest40826: (but it's a bit quite atm, so if no-one answers I'd try the mailing list next.)
[03:42] <Guest40826> okay
[03:43] <Guest40826> I've gotten it working by running "serve-branches --port=8080 --host=127.0.0.1 file:///{location here}"
[03:44] <Guest40826> but I'm trying to follow the documentation on setting it up in /etc/init.d
[03:45] <Guest40826> I put the loggerheadd file there and modified it so I thought it matched what I was in the other command
[03:46] <Guest40826> but now, when I run it (/etc/init.d/loggerheadd start) I get a message that says that "Loggerhead is running." but then it also says "This server is *not* listening on port 8080."
[03:47] <Guest40826> What would cause that?
[08:23] <bartio> does bzr has something like externals (subversion) or submodules (git)
[08:52] <bartio> could I use nested style for this? http://wiki.bazaar.canonical.com/SharedRepositoryLayouts
[08:52] <bartio> Could I use nested style for this? http://wiki.bazaar.canonical.com/SharedRepositoryLayouts
[08:58] <LarstiQ> bartio: what do you want from it? bzr-externals might cover your needs
[15:26] <Guest40826> I'm trying to use bzr in a centralized workflow, but I'm encountering an issue with permissions. Can someone tell me what the permissions should be set to for the repo and branch directories?
[15:28] <fullermd> You're probably wanting +w for the group (and, on a SysV-ish filesystem, setgid on the dirs too).
[15:57] <Guest40826> fullermd: Thanks, that did the trick!
[16:57] <einalex> hi! can someone tell me how to create a new standalone branch in python using bzrlib?
[17:12] <LarstiQ> einalex: how general do you want to be?
[17:12] <LarstiQ> einalex: bzrlib/builtins.py, cmd_init has the full logic from the bzr command
[17:13] <einalex> LarstiQ: thank you
[17:13] <LarstiQ> einalex: possibly bzrdir.create_branch() might be enough for you
[18:02] <esr> Can anyone explain why in a bzr tags listing some tags display as "?" rather than a revision number?
[18:03] <fullermd> That would be tags that point at revs not on the current branch.
[18:08] <esr> fullermd: Thanks, we suspected something like that.  We're adding bzr support to autorevision.  See #autorevision or http://www.catb.org/esr/autorevision/
[18:12] <fullermd> "Extracts metadata about the head revision from your repository."  What's it do with mtn, when there are multiple head revs?   ;p
[18:13] <dak180> fullermd: should read "Extracts metadata about the current revision from your repository."
[18:14] <esr> fullermd:  We don't have mtn support yet.  We've heard of it, but does it acxtually have...users?
[18:15] <fullermd> Oh, well, that just pushes the question back a step to when there are pending merges   8-}
[18:15] <fullermd> Well, I work on at least one project that uses it.
[18:16] <fullermd> I do love the genre of "VCS abstraction $foo" stuff, but it always seems to run into rocky waters.  There are just enough fundamental differences to trip you up, but few enough to keep you trying.
[18:17] <esr> fullermd: Yes, I know.  I wrote reposurgeon :-)
[18:17] <fullermd> Hm.  What does VCS_NUM do when there are multiple initial revs?  Count from one, or sum everything up?
[18:19] <esr> fullermd: Depends on the VCS.  We'd have to look at what the reporting commands we use do in that case.
[18:19] <esr> I don't thing that can happen at all with svn or a bzr branch.  But perhaps I'm wrong.
[18:20] <fullermd> Probably not in svn.  But it certainly can in bzr; I do it all the time.
[18:21] <fullermd> bzr/git/hg are all close enough in the revision data model that they should be the same in that.
[18:22] <esr> We just use what bzr revno gives back.  Do you have a better suggestion?
[18:24] <fullermd> Mmm.  Interesting.  revno is simple, and easy to describe.
[18:24] <fullermd> The downside is that, depending on how you treat your revision graph, it won't necessarily be monotonically increasing.  Using it for a build num wouldn't get along well with that.
[18:25] <fullermd> Of course, an argument could be made that in that case, you wouldn't be using a workflow that changes the mainline.  But then, Murphy usually has something to say about arguments like that.
[18:25] <LarstiQ> esr: is bzr version-info useful to autorevision?
[18:26] <LarstiQ> ah, already using it
[18:27] <fullermd> A count of the total number of revs should (assuming you're not engaging in history rewriting) be monotonic.
[18:28] <fullermd> 'course, it could make moves like "+1, +1, +2, +1, +683, +1, ..."
[18:28] <fullermd> Doesn't inherently damage utility as a build num, but could freak out users.  Maybe it's a good idea just for that reason   :>
[18:31] <fullermd> VCS_DATE reminds me of some thinking I was doing the other week about how VCS should store timestamps.  I got off into thinking about libtai for a while before I sobered up...
[18:33] <fullermd> Though that did leave me with the unpleasant "there is to great solution" hangover.
[18:33] <lifeless> fullermd: to great or no great
[18:33] <fullermd> See?  The hangover  :p
[18:35] <fullermd> Unfortunately, it lasts pretty much your whole life from the first time you get it.
[18:36] <dak180> fullermd: counting the total number of commits outside of the vcs tends to be very slow for any large repo and thus better avoided if it can be done, but yeah total number of commits generally is what i have been going for since, as you noted, it generally will not go down
[18:37] <fullermd> Yeah, I'm not aware of any non-silly way (grpe -c'ing log or the like) to get it through the bzr UI.  Probably could do it in a couple lines of bzrlib.
[18:38] <fullermd> Would be rather less than instantaneous, but probably could be not deathly slow.
[18:38] <fullermd> lifeless: BTW, I don't s'pose you glanced at that 'log' bug, and have a good answer for something I'm doing wrong, rather than it really being the nasty bug it looks like?
[18:39] <lifeless> fullermd: I didn't no. Whats the # again ?
[18:39] <fullermd> bug 1072513
[18:40] <lifeless> fullermd: (I'm now at HP Cloud Services, so even less involved in bzr day to day ;))
[18:40] <dak180> fullermd: something like that is there as a fallback for git, on a repo with +1000 commits it gets verrry slow
[18:40] <fullermd> Desc may have gotten long enough to call for a summary of the summary...
[18:41] <fullermd> Oh, even better then.  Just run a copy of bzr through there; everybody knows that moving stuff into The Cloud fixes everything.
[18:41] <lifeless> fullermd: it does
[18:42] <fullermd> And all this time, people thought telling me I had my head in the clouds was an _insult_!
[18:42] <lifeless> fullermd: so
[18:42] <lifeless> fullermd: first glance I don't see anything wrong
[18:43] <lifeless> fullermd: directories don't have a recursive change field
[18:43] <lifeless> fullermd: so foo/ only changes when foo it self is merged with another parallel add, or renamed or reparented or kind-changed.
[18:44] <lifeless> fullermd: foo/bar's changes should have no impact on 'bzr log foo'
[18:44] <fullermd> Er.  I'm pretty sure it should; log was fixed several versions back for that, wasn't it?  'cuz anything else is "unuseful".
[18:45] <lifeless> fullermd: foo/bar's graph doesn't change when foo/bar is merged into the mainline, and the -n0 codepath does fast deltas along the mainline in 2a using the common tree structure
[18:45] <fullermd> But even if that's not the case, it should still show the revs that added the dir.  And shouldn't start showing the other revs it "should" when I take out some of the --unchanged "Nada" revs.  Or give the same bad result with -v on the file.
[18:45] <lifeless> fullermd: oh indeed, you're right. See, i'm out of date :)
[18:46] <fullermd> Yeah, the 6 rounds of editing I did on the desc as I tried taking out and adding things really confused it up   :|
[18:58] <fullermd> There, I added a couple short comments summarizing the Wrong Answer(s).
[18:59] <fullermd> The bit where removing the --unchanged revs one at a time makes the other "correct" revs show up in log one at a time is just extra freakiness I found along the way of reproducing it, not the base bug I hit.
[19:08] <fullermd> And it's not a 2a shortcut tripping us up; does the same thing with pack-0.92.
[19:11] <lifeless> fullermd: cool (not really ;))
[19:11] <lifeless> fullermd: I wonder if its fallout from the change we did from downward to upward branch dotted decimal numbering
[19:12] <fullermd> Wow, that would be a long-standing bug.
[19:13] <fullermd> I have a hard time imagining that matters, but then you know that code better than I do.  My understand of it is "it does some lifeless stuff"   :p
[19:14] <fullermd> Well, I'm sure it'll make a tasty treat for one of those guys working on bzr day to day...
[19:15] <fullermd> What sorta stuff are you doing in The Cloud now?
[19:20] <lifeless> fullermd: https://github.com/tripleo/demo/blob/master/README.md
[19:21] <fullermd> Ew, they're making you post github links on #bzr?  That's just unnatural!
[19:21] <lifeless> fullermd: you asked ;P
[19:21] <lifeless> fullermd: my muscle memory is slowly adjusting, but I'm missing bzr's UI still in many subtle places
[19:24] <fullermd> It builds character, I'm sure   8-}
[19:26] <fullermd> I'd be interested in any "damn I miss this" and "wow I love this" notes you might scrawl out on the matter, if you get bored.  Could be useful info.
[19:32] <lifeless> the index is a nuisance
[19:32] <lifeless> its useful when you need it but its overhead 99% of the time
[19:33] <lifeless> having to unbreak commit to actually capture your changes on every run is a pita
[19:44] <fullermd> Yeah, that always seemed like such an odd mandatory thing.  So many people hold it up as the most awesome thing, and I keep thinking "Stockholm syndrome" every time I read about it...
[19:45] <lifeless> I very much miss bound branches
[19:45] <lifeless> I'm working with 6 folk on a single repo with ~ 5 files atm
[19:45] <lifeless> so we stomp on each other all the time
[19:45] <lifeless> recovery is fairly easy - you just save the commit message git pops up and then run rebase and then push
[19:45] <lifeless> but its a big WTF each and every time.
[19:47] <fullermd> Wuff.  And with that team/project, that probably happens every 3rd commit on average   ;p
[19:47] <lifeless> yeah
[19:47] <lifeless> we're rapidly expanding the surface area of working things, so that we can specialise for longer periods
[19:48] <lifeless> but we're expecting another 5-8 folk to join in the near term
[19:48] <fullermd> Think you'd need a rather thickier "branch" (for lack of a better word) data struct/model than git has to pull off adding that.
[19:48] <lifeless> so I'm not sure thats going to be a big win
[21:12] <Guest40826> I'm trying to use the automirror plugin, but whenever I do a checkin I get "bzr: ERROR: Server sent an unexpected error: ('error', 'JailBreak', "An attempt to access a url outside the server jail was made: 'file:///var/www/site/'.")"
[21:13] <Guest40826> file:///var/www/site/ is the location that I am trying to send the code to on checkin.
[21:13] <Guest40826> Does this have to do with permissions/ownership of the site directory or is there a bigger issue here?
[21:49] <Guest40826> Anyone know?
[22:07] <fullermd> I think that falls into "bigger issue", with the env that hooks run in not allowing access to arbitrary places in the FS.
[22:14] <lifeless> Guest40826: do you have a repo at /var/www/site/ ?