[10:20] hiya [10:21] I'm setting up a workflow for a company that hasn't used any VCS before (ew), and I need to make things simple enough to have them use it [10:23] one of the things I want to get is to have a "submit" command, which takes changes not present in the submit branch yet, and *merges* them in as a new revision, so that the submit branch, which serves as a central repo / coordination point always receives merges corresponding to logical "features", rather than just having revisions pushed from the dev branches [10:25] that's both for internal organisation purposes, as well as because they interact with an external SVN repo maintained by a customer; they want the customer to receive changes, but only in coarse "feature" chunks and not the fine-grained revisions the development actually happened in [10:27] and I want to set it up in a way which doesn't require having two different dev/ and submit/ (to perform the merges in) in addition to bzr://server/repo/central [10:27] only dev/ and bzr://server/repo/central [10:29] for that reason I'd like the "submit" tool to do something like create an internal .bzr/branch/submit if it doesn't exist yet, and then use that for merges in a transparent way [10:29] so, the question: does something comparable exist so that I could set it up with appropriate aliases and plugins, or do I need to cobble up my own plugin for that? [11:38] hey guys, what are the graphical methods in which you can view a branch evolution using ubuntu? [11:38] there were two ways and i was using one forgot what the package was called [11:46] anyone? [13:16] what's the fastest way to get the files in the tip of a branch over https? export? branch? checkout? checkout --lightweight? [13:25] jml: I don't really understand your question. If there's no smart server, then no method is particularly faster than the others, since you still need full history to build the files [13:25] assuming you mean faster in wallclock time spent on transferring things [13:26] *in the sense of [13:27] mathrick_: yes, faster in that sense. [13:27] then all should take roughly the same time [13:28] branch and checkout are identical, except that checkout will automatically push local changes to the parent branch, which doesn't make sense with https [13:29] I'd suggest plain branch, since that gives you most bang for the same buck. In case you need to do anything more with it, branch will have everything locally already, and the others won't [13:56] If you do anything other than "export" then you'll have a local branch you can update later on, without needing a full pull again [14:13] with a lightweight checkout it's not really true [14:13] since it's very little more than just the working tree [14:13] well, you can update it of course [14:13] but it needs network access [14:14] but yes, it will definitely be faster than re-exporting [14:21] I'm not sure about that... [14:22] Especially over a dumb server. [14:22] at the very least, it can skip over files that haven't changed [14:22] bu hmm\ [14:23] you're right, a dumb server probably won't see benefits of a lightweight checkout [14:23] In theory maybe. I'm not sure it works out that way in practice. [14:23] yeah [14:23] Even with a smart server, I'd hesitate at lesat 6 times before even considering a light checkout over anything slower than a 2ms/1gbit pipe. [14:24] oh it's not that bad [14:24] I've used lightweight checkouts many times for things like plugins which I don't want to work on [14:24] even ones with rather extensive history [14:28] btw, any comments on my question re: "bzr submit"? [14:29] mathrick_: I think I might have missed the question [14:30] oh, lemme pastebin it [14:30] http://pastebin.com/p3YAVsCv [14:30] jelmer: ^ [14:31] if there is some other workflow which'd make it easy that I haven't considered, I'm of course also interested [14:33] mathrick_: I don't think such a command exists at the moment. [14:34] I see [14:34] I think it'd be a worthwile addition [14:34] it seems sensible to me to use merges as a history organisation tool [14:34] patches welcome? :) [14:34] writing as we speak? :) [14:40] heh, OK [18:01] jml: hmm, my guess would be export, for a one off === yofel_ is now known as yofel [20:30] what is wrong with this? http://pastie.org/5173618 [20:30] I get ImportError: No module named fastimport [20:30] but it's there [20:42] You sure you're looking for the right one? The bzr 'fastimport' plugin relies on the python 'fastimport' library. [20:44] yeah... just realized that [21:01] what is the status of the bzr <-> git compatibility? [21:01] I see quite a few plugins, but I hear a lot of them don't work reliably [21:11] I'm not really the one to ask, since I've never used any of them. [21:11] My impression is that the various fast-import solutions work fine for one-way conversions/mirrors/etc. [21:12] And bzr-git does a reasonably good job with caveats for the "use bzr as a git client" sort of uses. [21:21] fullermd: you think fastimport is reliable? [21:22] I've not heard about any major issues with it. Which, to be sure, proves little, but... [21:22] It probably won't much help you if you're trying to _work_ in both VCSen. But for working in one and maintaining a copy in the other, I'm given to understand it does fine. [21:23] (or one-time conversion of course, though that's just a degenerate case) [21:57] branch.iter_merge_sorted_revisions(0, -1) the same as branch.iter_merge_sorted_revisions(None, None)? === iBasic is now known as BasicOSX [21:58] er: 1, -1 [22:01] or rather: builtins._get_revision_range([0, None], ... [22:01] s/0/1/ [22:15] I guess rev1 = RevisionSpec.from_string(str(tip)), RevisionSpec.from_string(None) === yofel_ is now known as yofel [23:08] wow, the git-remote-bzr in bzr-git is in really bad shape [23:30] felipec: in what way? [23:31] jelmer: many ways... but for starters I can't push [23:33] felipec: FWIW git-remote-bzr in bzr-git is experimental [23:34] felipec: how does push break? [23:35] jelmer: let me try again [23:36] jelmer: but also, it's not tracking the properly... a 'master' branch should appear in git [23:36] I'm writing a simple git-remote-bzr that already does that [23:41] felipec: I think it already does that, at least in trunk [23:41] felipec: either way, patches welcome :-) [23:44] jelmer: the code is too complicated and it's doing many things that are not neccessary [23:46] jelmer: http://pastie.org/5174396 [23:47] also, the push seems to be fetching _all the objects_ again, which is certainly not needed [23:47] felipec: ah, that's happening because you're pushing into a bound branch I think [23:47] jelmer: what is that? [23:48] jelmer: in my remote-bzr I'm able to push to the same branch just fine [23:48] although only once [23:49] felipec: what is your remote-bzr ? [23:53] jelmer: http://pastie.org/5174415 [23:53] felipec: ah, so that's essentially the same thing as git-bzr is doing? [23:55] jelmer: yeah, but git-bzr doesn't use git's remote helper functionality [23:55] felipec: I'm pretty sure at least one of its incarnations does [23:57] jelmer: you mean bzr-git? [23:57] felipec: no, git-bzr [23:57] (I'm involved in bzr-git/bzr-fastimport) [23:58] and actually I'm seeing the same issue mentioned in git-bzr-hg: AttributeError: 'BTreeBuilder' object has no attribute '_find_ancestors' [23:58] well, I don't see it here: https://github.com/pieter/git-bzr, or here https://github.com/termie/git-bzr-ng