[00:39] <GungaDin> How can I branch into a remote location without having to branch, push & reconfigure?
[01:01] <Peng_> GungaDin: What? "bzr push"?
[01:02] <GungaDin> no, I want to immediately branch from a remote place to a remote place.
[01:02] <GungaDin> I think I managed simply by specifying both urls.
[01:02] <Peng_> Oh.
[01:06] <mkanat> spm: I don't know if you saw, but we pushed an actual fix for one of the bugs lately, so you might want to update codebrowse to loggerhead trunk if you haven't in the last two days or so.
[01:10] <spm> mkanat: excellent! ta; will do!
[02:36] <thumper> mkanat: an actual fix?
[02:36] <thumper> as opposed to a fake fix?
[02:36] <mkanat> thumper: I checked in a fix that didn't fix it, at first.
[02:36] <thumper> ah
[02:36] <thumper> mkanat: which bug?
[02:37] <mkanat> thumper: https://bugs.launchpad.net/loggerhead/+bug/420738
[08:44] <jam> wgrant: didn't you recently post an lsprof of 'bzr branch' to a bug? Do you know what bug that was?
[08:45] <mwhudson> jam: probably https://bugs.edge.launchpad.net/bzr/+bug/562666
[08:45] <spiv> jam: 562666
[08:45] <wgrant> Yeah, that's the one.
[09:20] <wgrant> lifeless: 13 minutes to locally branch devel.
[09:49] <lifeless> wgrant: ok
[09:53] <lifeless> wgrant: we have some results
[10:03] <ziminq> hi all, how can I commit part of a file's changes? something like 'git add -p'?
[10:04] <spiv> ziminq: 'bzr shelve'
[10:05] <ziminq> spiv: thanks, i'll take a look at this :-)
[10:05] <spiv> ziminq: e.g. use bzr shelve to temporarily set aside the changes you don't want to commit yet, then you can commit, and then you can unshelve again.
[10:06] <ziminq> spiv: yeah, just what I want. similar to idea of git stash.
[10:09] <wgrant> lifeless: Aha. Panic panic?
[10:29] <awilkins> Someone remind an idiot how to push a new branch into an empty SVN repository?
[10:29] <jelmer> awilkins: hey
[10:30] <jelmer> awilkins: bzr push <repo>/trunk
[10:30] <awilkins> Hello Jelmer
[10:31] <lifeless> wgrant: a 12% improvement about to be put up for review
[10:32] <awilkins> jelmer, I'm getting "http does not support mkdir()"
[10:33] <awilkins> jelmer, And I'm an idiot because I don't have bzr-svn installed   :-S
[10:34] <awilkins> Thaaat works better
[10:39] <jelmer> awilkins: that'd explain it :-)
[10:43] <wgrant> lifeless: Ah, great!
[10:43] <wgrant> Not so great, however, is that my lp:linux checkout is about to reach 2.5GiB.
[10:45] <jelmer> wgrant: `have you tried repacking it
[10:45] <jelmer> ?
[10:45] <wgrant> jelmer: Well, it's still downloading..
[10:47] <jelmer> wgrant: hmm, that's odd - I think it was only around 300Mb here..
[10:48] <jelmer> wgrant: you're not accidentally fetching into a 1.9 repo?
[10:48] <wgrant> jelmer: Yes, it was just a few undred megabytes when I tried it a few weeks ago.
[10:48] <wgrant> jelmer: No, fresh checkout into /tmp, which is not a shared repo.
[10:49] <jelmer> wgrant: hmm
[10:53] <mwhudson> i guess it would be interesting to get a losa to run du a couple of times
[11:11] <lifeless> wgrant: srsly?
[11:16] <wgrant> lifeless: Yeah, 2.5GiBwas shown in the progress indicator thingy, but .bzr ended up at only 475MiB.
[11:18] <awilkins> Does it transfer compression groups or does it stream their content?
[11:19] <awilkins> e.g. - if pulling and you ask for a revision stream that's in a compression group does it just send the group so you can hit that later on?
[11:27] <Tak> does bzr-git support dpush?
[11:27] <jelmer> Tak: yes
[11:27] <Tak> but not regular push yet, correct?
[11:28] <jelmer> Tak: right, though it might not be too long before it supports regular push
[11:28] <Tak> dpush works for me for now
[11:38] <Tak> is there a known good way to dpush to github?
[11:39] <jelmer> bzr dpush git+ssh://git@github.com/tak/repo
[11:43] <cbz> What's the difference?
[11:43] <Tak> http://paste2.org/p/822944
[11:45] <jelmer> cbz: between what?
[11:46] <cbz> Oh - it strips the metadata
[11:47] <cbz> In working with git i presume the model isn';t one of rebase and then push - but that one pushes all one's revisions upstream
[11:48] <jelmer> cbz: not sure I follow, in git rebase seems to be used a lot
[11:49] <Tak> that's with branch, commit, dpush
[11:49] <cbz> I just meant that when working with subversion one has to rebase ontop of the latest chanegs in the remote repository before pushing upstream
[11:49] <jelmer> tak: that's a known issue in trunk at the moment
[11:49] <Tak> oh, ok, is there a known good rev?
[11:50] <jelmer> Tak: I'd use a release
[11:54] <Tak> oh, hmm, so it actually pushed my revision
[11:57] <lifeless> awilkins: neitherish
[11:59] <cbz> I'm getting this error when doing a bzr pull: bzr: ERROR: sqlite3.OperationalError: database is locked
[11:59] <cbz> is there a way of cleaning up the lock?
[11:59] <jelmer> cbz: you have two bzr processes accessing the same svn repo
[12:00] <jelmer> cbz: you can install python-tdb to work around that issue (it allows concurrent access)
[12:00] <cbz> jelmer: something must have left the lock behind. The only other thing running is a tbzrcache process
[12:00] <mwhudson> and then you can mangle the subversion.conf file :)
[12:01] <jelmer> cbz: I wouldn't be surprised if that's what accessing the database..
[12:03] <cbz> Is the lock a per user or per repository setting?
[12:03] <cbz> i've exitted tbzrcache and stil get the same error - any way of cleaning up?
[12:59] <jelmer> cbz: it's per repository
[12:59] <jelmer> cbz: It shouldn't give that exception if there aren't any processes using that cache
[13:00] <jelmer> I guess you could remove the cache, if windows will allow you
[13:05] <cbz> Hmm - only a reboot fixed it in the end
[13:16] <hersonls> Hi, im new in layout of cvs and how is the best way to create a branche from a trunk in the same repo?
[13:17] <Kamping_Kaiser> cvs?
[13:19] <hersonls> yeah, layout like svn, trunk/ tags/ branches/ - before i never use this, only one directory
[13:19] <hersonls> i see a svn tutorial to use a svn cp trunk/ branches/0.1 - for exemple
[13:19] <hersonls> how the best way into bzr
[13:21] <Peng_> "bzr branch"?
[13:23] <hersonls> i dont know about that, i dont understand how this work fully... but bzr branch creat a copy of a branch, is the correct way? branch inside branch?
[13:28] <Peng_> I think you should read the tutorial or something.
[13:28] <Peng_> "bzr branch" creates a branch.
[13:29] <Peng_> Which starts out as a copy of the branch you're branching from, yes.
[13:29] <hersonls> this i understand
[13:30] <hersonls> my question i how to work with this layou branches/ trunk/ tags/
[13:30] <hersonls> i read in same blog's, the trunk is a production branch and when i make a modifications i make a copy from trunk to branches/
[13:31] <hersonls> right?
[13:34] <Peng_> Why do you want to work with that layout?
[13:35] <Peng_> I've never uinderstood the point of consigning non-trunk branches to some "branches" directory.
[13:35] <Peng_> And in Bazaar, tags are dcreated with "bzr tag".
[13:36] <hersonls> so, i can make a tags so easy?
[13:38] <hersonls> so the best way is making a tags?
[13:45] <Peng_> The "best way" for what? When you need a tag, make a tag. When you need a branch, make a branch.
[13:45] <hersonls> =)
[13:54] <awilkins> hersonls appears to be used to SVN
[13:55] <awilkins> SVN implements tags and branches by convention only using the ability to copy a SVNFS inode
[13:55] <hersonls> awilkins, haha, i'm reading a good article about this
[13:55] <hersonls> and i like that
[13:55] <hersonls> http://www.scribd.com/doc/10965126/ccbazaar
[13:56] <awilkins> I liked SVN a lot ; I converted 3 shops to it, I still administer SVN repositories, but I'm a born-again DVCS convert
[13:58] <hersonls> the only problems i have with bzr is a permission in repo, when one user make a push when anothe make too make a access denided using sftp
[13:58] <hersonls> =(
[14:03] <beuno> hersonls, you need to have them both in the same unix group
[14:05] <hersonls> yeah, i see in this - chmod 770 /bazaar/bzr; chmod +s /bazaar/bzr
[14:07] <Peng_> Does the sticky bit work over SFTP?
[14:08] <maxb> The sticky bit is +t, not +s
[14:08] <Peng_> Oh. :P
[14:08] <poolie> Peng_: do you mean sticky or setgid? in any case
[14:08] <maxb> +s/+t work at the filesystem layer, so it doesn't care how you're accessing it
[14:08] <poolie> some servers filter out setuid/gid
[14:09] <Peng_> I remember OpenSSH having issues with something, but IIRC it was just the umask?
[14:09]  * Peng_ has never used any of the unusual bits, so he doesn't know them well.
[14:10] <maxb> The problem with using setgid directories and a common group is it requires that users' umasks do not mask group permissions
[14:12] <Lor> Hi, is there any documentation on how plugins are supposed to handle locking?
[14:30] <lifeless> jam: https://code.edge.launchpad.net/~lifeless/bzr/command-help-bug-177500/+merge/25055
[14:40] <jelmer> bzr send not defaulting to --strict anymore is great :-)
[14:45] <jam> lifeless: i believe I already reviewed
[14:45] <lifeless> jam: ok
[14:45] <lifeless> ah yes
[14:45] <lifeless> stale webby pagy
[14:53] <Lor> So, are plugins supposed to call tree.lock_read(), or are lock operations considered to be internal to bzrlib?
[14:53] <lifeless> only the highest level functions take locks automatically
[14:54] <Lor> Are the locks recursive?
[14:54] <lifeless> any non-trivial plugin will be likely taking locks explicitly
[14:54] <lifeless> reentrant? yes
[14:54] <Lor> All right, then it shouldn't be too hairy.
[14:57] <Lor> Incidentally, how long is the bzr codebase supposed to be python 2.4 -compatible? The with-statements introduced in 2.5 would make writing critical sections much easier.
[14:58] <lifeless> we were talking about this earlier
[14:58] <lifeless> I'm not sure, is the short answer ;)
[14:59] <lifeless> but we can add glue for with to bzr without being 2.4 incompatible
[15:00] <Lor> You mean, make it easier for plugin writers to use with-statements (and lose 2.4-compatibility) if they choose, but refrain from using them in the core?
[15:01] <Lor> Of course, the glue itself is pretty trivial: http://pastebin.com/nmfpHHsb
[15:05] <Lor> By the way, here are some plugins I intend to write. Please tell if you are aware of something similar already underway.
[15:05] <Lor> bzr-mtime: store mtimes of added and modified files under .bzrmeta/mtimes. Add a merge hook for that file to select the newest mtime.
[15:07] <Lor> bzr-snapshot: allow making "snapshot" commits, so that the latest non-snapshot revision is tagged as such. A "real" commit is then actually a final snapshot, plus a merge into the latest non-snapshot revision.
[15:08] <Lor> (This allows storing an intermediate, ugly state of the tree, but since it ultimately happens in a branch that gets merged back, the final history will look cleaner)
[15:09] <Lor> Finally, a plugin that traverses through the working tree and interactively asks the user what to do with each unknown file: delete, add or ignore henceforth.
[15:10] <lifeless> I'm not aware of anything underway for those things
[15:11] <Lor> All righ.t
[15:12] <Lor> (I do think that the mtimes should be stored by the core in the inventory, though.)
[15:12] <lifeless> well we have the time of the commit
[15:12] <lifeless> which is more accurate in many ways (consider e.g. revert, touch, etc)
[15:13] <Lor> I don't mean that the mtimes should be utimed to the working tree during checkout.
[15:14] <Lor> But they are useful information.
[15:14] <Lor> Suppose I edit a file in the working tree but forget to commit, and after some weeks edit some more and then commit.
[15:15] <Lor> Then it's nice to retain the information about the earlier editing.
[15:15] <jelmer> lifeless: ping
[15:15] <lifeless> pon
[15:16] <jelmer> lifeless: When would be a good time to look at colocated branches / foreign branches this week?
[15:16] <lifeless> tomorrow perhaps ?
[15:18] <jelmer> lifeless: there's quite a few session I have to attend tomorrow, thursday or friday would work better for me
[15:18] <lifeless> sure
[15:28] <Lor> Is there some specification for file-ids?
[15:29] <Lor> I think it would be good to have a fixed, custom file-id for the mtime file, but I'm not quite sure if there is some convention for choosing the id.
[15:31] <poolie> jam, do you mind if i put you down as PP next week?
[15:32] <jelmer> Lor: I don't think there's any hard-coded file ids other than the now deprecated TREE-ROOT
[15:34] <Lor> But per-tree metadata files that are managed by plugins probably ought to have hard-coded file-ids, since otherwise bad things will happen if two unrelated repositories get merged.
[15:34] <Lor> s/repositories/branches
[15:35] <Lor> On the other hand, _really_ bad things will happen if two distinct plugins choose to use the same file-id.
[15:36] <Lor> A namespace convention would be useful for preventing collisions.
[15:39] <lifeless> Lor: the path is sufficient, I think. the plugin can handle merging appropriately
[15:40] <Lor> Uh, how can it be handled appropriately if two mtime files have been created in two unrelated branches, with different file-ids, and then those get merged (joined, in practice)?
[15:42] <Lor> Hm. Doesn't the .bzrmeta directory (which, I gather, is the officially recommended place for data stored by plugins) also have a fixed file-id?
[15:42] <Lor> Or shouldn't it?
[15:42] <spiv> No, it doesn't have a fixed file-id.
[15:42] <spiv> It might be nice if it did.
[15:42] <spiv> But even the tree root doesn't...
[15:43] <Lor> Oh, that has changed?
[15:43] <Lor> How then are two unrelated branches merged?
[15:44] <Lor> Ah, it's an error nowadays.
[15:44] <spiv> Hmm, not sure how different tree roots affect it, but I'm fairly sure "bzr merge -r 0..-1 $unrelated" manages to do something useful.
[15:45] <Lor> I always thought that it's really pretty that every branch has a common ancestor.
[15:45] <Lor> But obviously that wouldn't work with nested trees.
[15:46] <Lor> So, um, with nested trees, file-ids have to be unique throughout the hierarchy?
[15:47] <lifeless> yes
[15:47] <Lor> Then, obviously, all subtree-specific metadata files also have to have unique ids.
[15:47] <lifeless> yes
[15:48] <Lor> Well, that decides it.
[15:50] <Lor> So then I need a hook to be run during a join operation, one that migrates the metadata from subtree/.bzrmeta/mtimes to .bzrmeta/mtimes
[15:52] <Lor> Except that no hooks are currently run during WorkingTree.subsume...
[16:12] <spiv>   
[19:34] <dwt> Hi all, I've got a project that is a checkout of a google code repository, but that I also publish to my another repo on my homepage
[19:34] <dwt> now I always need to type 'bzr push && bzr push bm:upstream' to push it to these locations (the bookmarks plugin already helps a ton)
[19:34] <dwt> BUT
[19:35] <dwt> I'm sure there is an even better way to push to these two locations
[19:35] <dwt> (as I always want that)
[19:35] <dwt> but I couldn't find anything in the plugins section or with gui
[19:35] <dwt> sorry, in the wiki
[19:35] <dwt> or with google
[19:35] <dwt> so thats why I'm asking here
[19:35] <Lor> I'm actually also interested in this.
[19:35] <dwt> So please help, how to spare typing those extra characters?
[19:36] <dwt> Lor: Yay, now we're two! :)
[19:36] <IslandUsurper> dwt and Lor, make an alias for, say, "push-all"
[19:36] <Lor> If your entire problem is typing more, then... echo.
[19:37] <Lor> I have (or will have) a slightly more complicated situation, though.
[19:37] <dwt> IslandUsurper: alias means that it is global and not local to one repository, right?
[19:38] <IslandUsurper> dwt, I think you can have both
[19:39] <IslandUsurper> I'm not sure about it now, though. I may have been thinking of git :-/
[19:39] <dwt> IslandUsurper: Those seem to be defined in ~/.bazaar/bazaar.conf
[19:39] <dwt> can I have one of those per project too?
[19:39] <IslandUsurper> there's a branch.conf
[19:40] <IslandUsurper> in .bzr/branch/branch.conf
[19:45] <dwt> http://wiki.bazaar-vcs.org/ConfiguringBzr Aliases cannot be specified in locations.conf or branch.conf
[19:45] <dwt> :-(
[19:45] <dwt> Other ideas?
[19:45] <Lor> Why does this need to be branch-specific?
[19:45] <dwt> Well, repository specific would be fine for me
[19:46] <dwt> but as far as I understand that means it has to be in locations.conf or branch.conf
[19:46] <dwt> right?
[19:47] <Lor> There are all kinds of kludges (or non-kludgy Real Solutions) you could do, but I'm not sure if they're worth the effort.
[19:57] <dwt> Hrm…., well, I can always resort to makefiles / scripts as a last resort
[19:57] <dwt> I'd rather hoped to avoid that though
[19:59] <Lor> It's pretty simple to write a plugin that modifies the push command so that multiple push_locations are supported.
[20:01] <Lor> Frankly, the api is a bit messy, though.
[20:01] <Lor> Too much of the logic of ordinary commands is in the actual command classes.
[20:02] <Lor> Doing an ordinary push from python code should preferably just be a single method call without parameters.
[20:25] <dwt> Yeah…. Well, maybe if the internal implementation is simplified I might give it a go
[20:25] <dwt> :-)
[20:35] <Lor> Wait a sec... a commit hook only gets access to the branch, not the working tree?
[20:38] <dwt> uhm, yes/no/maybe?
[20:39] <dwt> Sorry, I have no knowledge of bzrs internals. :)
[20:45] <Lor> Ah, I was looking at pre_commit when I really should have used start_commit.
[20:54] <Lor> If the current working tree is in a state of an uncommitted merge, is there a way to find out which of the currently modified/added files came from the merge without conflicts?
[20:57] <Lor> Also, what's a ghost revision?
[21:16] <Lor> Why doesn't Tree.changes_from() support specific file_ids?
[21:16] <Lor> It seems funny that an api supports specifying an argument as a path (which is then converted into an id) but not directly as an id.
[22:32] <jelmer> moinmoin