[00:00] what do CVS users do? their version ids are N-length - e.g. 1.1.1.1.1.1.1.1.1 [00:00] this can't be a new challenge [00:01] "For the purposes of this module, a version "number" is a sequence of positive integer values separated by one or more decimal points and optionally a single underscore." http://search.cpan.org/~jpeacock/version-0.74/lib/version.pod [00:01] however, the standard is to just have three digits, separated by decimal points [00:01] heh [00:02] you could just do MAJOR.revno [00:02] for use case 1). [00:03] but i'm not going to want to release a new minor version every time i do a commit [00:03] so [00:03] and skipping minor version numbers might be confusing for users [00:04] you were talking about tagging every commit [00:04] this would have had the same behaviour [00:04] yes, but they'd be tagged with X.Y.revno [00:04] A branch might be a better way to tackle this. [00:04] not with X.revno [00:05] if you have two branches [00:05] one branch, call it 'releases' [00:05] every commit there is a release you are doing. [00:06] another branch, your trunk or mainline [00:06] every commit there is just a commit [00:06] hmm [00:06] then, to do a release, merge to the release branch and commit [00:06] i actually haven't worked with multiple branches of a single project in bazaar [00:06] X.Y.revno in the release branch will go up slowly [00:06] so i'm not sure i understand how this would work exactly [00:06] or even X.revno [00:07] well, have a play [00:07] make a scratch project, follow the tutorials [00:07] get a feel for it [00:07] ok [00:08] thanks for your help, lifeless [00:08] np [00:09] what you're describing might be something like what's on this page... https://www.fmios.org/wiki/Discussions/BzrLayout [00:09] under the "Package Versioning" section near the bottom of the page [00:10] "The hope is that future development for each package will follow a milestone path, where milestones are set for a specific release, and when the milestones have been achieved in dev, the branch will then be copied off to the release version for that package. At that point the package is considered released and no further enhancements will be allowed to the release branch, only bug fixes. Enhancements and such will be allowed to continue in the dev branc [00:10] h of the package." [00:21] so, would i do something like this? "mkdir myproject/dev ; cd myproject/dev ; bzr init ; vi my_perl_module ; bzr add my_perl_module ; bzr commit" etc... and work in "myproject/dev" and then when i have a build ready for release do "cd myproject ; bzr branch dev 1.0" to create a copy of the dev branch? [00:23] or i guess that's what that fmios.org page is suggesting [00:24] you seem to be suggesting doing "cd myproject ; bzr branch myproject releases ; cd releases ; bzr commit" [00:25] i'm not sure what advantage either of these approaches gives over simply tagging revisions with "X.Y.revno" [00:26] that seems much more efficient... why have these superfluous copies of the main development branch sitting around when all the important information in the copies would already be in the main development branch to begin with? [00:30] well [00:30] they are not superfluous; and a shared repo means you don't have copies either [00:30] when the files are checked out, isn't the information copied? [00:31] depends [00:31] i guess i could delete the files after the release, but then that would defeat the purpose of having a separate release branch [00:31] what info you mean. your working files yes. [00:32] yes, the working files [00:32] the historical data base - optionally no. See bzr help init-repo. [00:32] and you could use zap-tree to remote teh release tree temporarily. [00:32] still, if you haven't actually sat down and simulated with a trial project, I urge you to do so [00:32] well, i did just try it [00:33] things become much clearer when you have actually worked with 'bzr merge' and multiple branches etc [00:33] with very basic files [00:33] i haven't tried merging them [00:33] but if i'm only going to be using a separate branch for release purposes, i shouldn't need to merge branches [00:33] and i'm still not sure what advantage i'd get from having a separate release branch [00:34] over and above what i'd get from simply tagging the development branch with a version number [00:34] I think you just need to choose something and run with it [00:34] if it turns out not to work, change your mind [00:35] good idea [00:35] the only thing you should do right now is to make sure that you will be able to change your mind without too much trouble [00:35] e.g. by how you allocate x.y and z. [00:37] yep.. that makes sense [00:37] thanks again, lifeless [02:13] * ig1 food [02:15] I've been noticing `bzr serve` instances staying in CLOSE_WAIT a long time. [02:57] abentley:ping [02:57] ? [02:57] let's try that again - ping abentley [02:57] hi [02:57] Hi. [02:58] re switch ... [02:58] looking at cmd_update ... [02:58] is it appropriate to refactor most of that into a module ... [02:58] that switch uses instead of its own update function? [02:58] I don't know. [02:59] in particular, jameinel had some feedback re pending merges ... [02:59] that seem to be better thought though in cmd_update [02:59] I've advocated that there should be no "switch" command. Update should just take a branch, like it already takes a revision. [02:59] also, I'm thinking about future -r support for update [03:00] interesting [03:00] Okay, maybe it doesn't already. [03:00] But people think it's counterintuitive. [03:01] conceptually, I've always thought of switch as bind+update [03:01] OTOH, update has some pretty weird behavior, if the working tree is out of date with the branch, and the branch is out-of-date with the master branch. [03:02] but there is next to no code from bind or update used in switch currently [03:02] Switch isn't bind at all. [03:02] So that part makes sense. [03:04] The implementation of bzrtools.switch.switch and bzrtools.switch._update is reasonably short, but if we can get more code reuse, that's usually a good thing. [03:04] ok, so bind sets the master branch attribute ... [03:05] which switch ties a tree to a branch, yes? [03:05] s/which/while/ [03:06] Right. [03:06] any thoughts on pending merge handling? [03:06] I don't remember John's comments. [03:07] is it ok for switch to fail and tell the user to revert pending merges before switching? [03:07] or commit of course [03:08] i.e. tell them to commit or revert [03:08] Yes, I think that would be fine. [03:09] thanks [03:27] hello ig1, abentley [03:27] hi poolie [04:06] New bug: #72227 in bzr "bzr fails when run within certain Python code trees" [Medium,In progress] https://launchpad.net/bugs/72227 === keir_ is now known as keir === Verterok is now known as Verterok_ [07:21] I's back [07:21] mornin' lifeless === m_stone is now known as m_stone|home [08:08] * ig1 food [08:16] pattern: regarding perl modules version numbers, notice that 'version' itself has always used X.Y revions numbers (as most of packages on CPAN do) [08:17] then, if you use MakeMaker, there is a dist target in the makefile, use it to define your version when you produce a new release (Module::Build certainly provides the same target) [08:22] finally if you look at various packages you will see that the revisions are not always consecutive so using X. will be perfectly acceptable and understood by users [08:24] vila, when you say "'version' itself", what are you referring to? [08:25] the version module? [08:25] the 'version' package which is now part of perl itself [08:25] ah [08:25] http://search.cpan.org/~jpeacock/version-0.74/ [08:25] yes, it uses an X.Y version string [08:26] some modules use X.Y and others X.Y.Z [08:26] so X.Y.Z is *not* mandatory [08:26] that's true [08:26] but the point is that it's not just a single integer version string [08:26] it's either X.Y or X.Y.Z [08:26] but bazaar only provides a single integer [08:27] so i have to create at least X.Y myself [08:27] as long as you provides monotonically increasing numbers you'll be fine === me_too is now known as too_short [08:27] you can use 0. [08:27] well, nothing will break if i do that === too_short is now known as me_too [08:27] that's the point [08:27] but it might be a bit confusing for the users when i jump from 0.23 to 0.198 [08:27] kiss principle [08:29] hmmm, you'll have to check that but if you add you own code to create the release (dist target in makefiles) you can address that [08:29] it's not just a matter of having the dist target being numbered correctly [08:29] and most package writers handle their release numbers manually anyway [08:30] an internal version number for the perl module itself is also necessary [08:30] so that module users can check and request particular versions of my module [08:30] so that version number needs to go in to the perl module itself [08:31] i'm probably going to do that using a templating system (probably Template Toolkit) [08:33] so i'll just have "$VERSION = [% VERSION %]" in the perl module, and in Makefile.PL i'll run some command to fetch the version number from bzr and substitute it in to the perl module [08:34] fine [08:34] so the development will be on mymodule.pm.in and Makefile.PL will turn that in to mymodule.pm [08:35] and only mymodule.pm.in will be versioned [08:36] you may also look at creating your own template for bzr version-info [08:37] i don't understand [08:37] what kind of template? [08:38] hi [08:38] first, congrats for knitpacks! I just did some experiments, and it cut down the initial push time from 80 seconds to 46 [08:39] but I have troubles with pushing some additional revisions [08:39] bzr: ERROR: Could not understand response from smart server: ('error', "") [08:39] (both sides are running bzr 0.92.0 final) [08:39] is this known? [08:39] pattern: look at bzrlib/cmd_version_info.py [08:39] pitti: check the packs tag on malone :_ [08:40] ah, good hint; seems to be https://bugs.edge.launchpad.net/bzr/+bug/156546 [08:40] Launchpad bug 156546 in bzr "unable to push to packs-based smart server" [High,Triaged] [08:41] vila, ah, you mean some kind of script that will interface with bazaar to get the version information i want to use in my perl module? [08:41] yes [08:41] unfortunately, i don't know python [08:41] does bazaar have a perl interface? [08:41] not yet :) [08:41] i mean to learn python someday [08:41] try bzr version-info --format=python [08:42] pattern: python has good surprises for you coming from perl :) [08:42] or write a perl formatter :) [08:43] yep :) [10:13] How do I undo a 'bzr pull'? [10:13] I mistakenly pulled from foo to bar, and now I want bar to go back to its revision level before the pull [10:13] similar to 'bzr uncommit' [10:14] If you know what revision used to be the head, you can just pull it. [10:15] and that will cause the current branch to lose the revisions after that point? [10:16] 'bzr pull -r82 .' => "No revisions to pull." [10:16] You need --overwrite since it's not going strictly forward. [10:16] (current branch is at r87, I want to lose everything after r82 because they came in from the mistaken pull) [10:17] The revs will still be in its repository, of course. But the branch won't refer to them, so... [10:17] that's fine, I'm using a central repository. [10:18] okay, that seems to have done the trick [10:18] fullermd: thanks. [10:18] next question: [10:19] the reason I wanted to undo it was because I wanted to pull only *some* changes from foo into bar [10:19] eventually, all of foo will be pulled in, but not yet [10:19] so how can I pull specific revisions? [10:20] Well, you can pull up to a given rev rather than the head with -r... [10:20] right, but that's exactly the situation I wanted to undo [10:21] I want to specify "pull revision 87 and no other revision from foo into bar" [10:22] You can approximate it by gettings its changes with a cherry-picked merge. But there's no way to get rev 87 itself without getting its antecedents. [10:23] That may or may not lead to extra fun down the line when you merge the rest of the revs. [10:23] mmm. a cherrypicked merge will result in forever-divergent history, won't it? I want to be able to later align the histories fully with a pull. [10:24] Well, if you don't make changes other than the equivalent of r87, you can later just do a pull --overwrite and discard that new rev you made. [10:24] I hear the spectral voices of my darcs friends laughing and pointing... [10:24] (as long as nothing else is based on it, of course) [10:25] They're not laughing and pointing. They will though, as soon as their history finishes resolving itself. Might want to budget some time in 2015 to deal with the embarassment. [10:25] I don't fully understand that, but I assume it's a comment on the performance speed of darcs merges. [10:27] fullermd: by "discard that new rev you made", do you mean the rev created by the cherrypicked merge? Discard it because, with a 'pull --overwrite', the change will effectively be made anyway? [10:28] Well, you're wanting code that does a certain thing. After you do the cherrypick, that code will be in both r87, and your newly-created cherrypick r83. [10:28] So if you then want to re-duplicate the other branch, a --overwrite will toss away your cherry-83, but since you'll have that 87 anyway at the point, it doesn't matter. [10:29] Assuming no work is ever based off that cherry-83, that is. [10:40] fullermd: thanks, you've at least improved my understanding of what I'm asking :-) [10:42] http://blogs.gnome.org/newren/2007/11/17/adoption-of-various-vcses/ [10:54] night all [10:54] keir_: be good to find out what the date: thing they hate is [10:58] yes [10:59] lifeless, we need to get some big projects on board! [11:12] Packs for local and more SS for remote are probably 2 of the biggest steps to take there. === cprov-away is now known as cprov === othermaciej_ is now known as othermaciej [13:17] Hi, is it possible to branch / merge / push / pull to/from not-mounted samba shares? === mrevell-lunch is now known as mrevell [13:17] wam: you mean push smb:///whatever ? [13:18] wam: i'm not aware of anything that would let you do that [13:18] mwhudson: would it be easy to write a plugin for that? [13:18] mwhudson: bzr is python-only, so maybe I could look at this. [13:18] (as I know python ;)) [13:19] wam: it's probably possible, yes [13:19] i mean, there's a webdav plugin that mostly works and samba can't be that painful :) [13:20] mwhudson: ok, thanks. So I'll see if I have a use for it and maybe code it. A customer of mine works on windows and the working-dir is smb only. So I'd like to install a branch there and have merges as smoothly as possible ;) === bac_afk is now known as bac [13:22] wam: good luck :) === jamesh_ is now known as jamesh === bac_afk is now known as bac === bac_afk is now known as bac === bac is now known as bac_afk === bac_afk is now known as bac === cprov is now known as cprov-lunch [14:19] hi all [14:19] abentley: is BB down ? Firefox timeouts trying to connect [14:19] or is it times out ? ;) [14:21] You trying to connect via htpps? [15:00] fullermd: not even :) === jam-laptop is now known as jam [16:05] New bug: #163849 in bzr-eclipse "display revision log on uncommit" [Undecided,New] https://launchpad.net/bugs/163849 [16:31] sigh [16:31] jelmer: ?? [16:31] where are the days when you could hit Ctrl+C to abort the commit if you changed your mind [16:31] I do that now [16:31] now I have to use uncommit all the time :-) [16:32] the commit happens to fast? [16:32] yup, somewhat like that :-) [16:33] the price of progress, I guess [16:33] You could not use "-m" so that you can cancel without saving from your text editor [16:35] yeah, I may give that a try - thanks [16:36] personally, I would just 'bzr uncommit --force" [16:38] good reason not to use checkouts, that [16:38] less embarrassing [16:38] mwhudson: bzr uncommit removes it from the bound location, too [16:38] as long as nobody goes spelunking with "bzr heads" [16:38] jam: true, but it might send email, etc [16:38] mwhudson: yeah, but my client always sends email [16:38] even for local stuff :) [16:39] well, I have a .../private/* directory [16:39] for stuff I don't advertise [17:01] New bug: #163860 in bzr "feature request: script to generate consistent copy of shared repository ('hot-backup.py in svn terminology)" [Undecided,New] https://launchpad.net/bugs/163860 [17:03] I'm playing around a bit with bzr and I'm wondering if this error is expected behavior ? : http://pastebin.com/d24d654d5 [17:05] woei: blergh, even if it were an error to try and do that, you shouldn't get that kind of report [17:05] indeed [17:21] does anyone know a way of doing this: http://paste.ubuntu-nl.org/45128/ without requiring a checkout ? [17:28] mwhudson: I don't believe the Merge code works without a limbo directory from a WT [17:29] jam: what i want to avoid is the lengthy tree-building process for launchpad [17:30] mwhudson: have you tried it with an empty WT? [17:30] ah, but that wouldn't work either [17:30] wait a second [17:31] why are you doing a 'show_diff_trees' of revtree versus basis_tree [17:31] jam: won't that take all the history of merge_source_branch? [17:31] don't you want the diff of the on-disk tree ? [17:31] (after the merge) [17:31] to its basis? [17:32] jam: that's what i'm getting, it seems [17:32] basis may not be a good name here [17:32] ah [17:32] ok [17:32] yeah, basis_tree is usually: tree.basis_tree() [17:32] which is the last committed version [17:32] oh [17:33] I would just call it "tree" [17:33] so revtree = basis_tree.basis_tree() is shorter and equivalent? [17:33] jam: let me rename somethings and repaste :) [17:33] mwhudson: and for DirState working trees is faster [17:34] jam: fine, but the slow part is create_checkout [17:34] because it has already written things down for faster comparisons [17:34] mwhudson: sure. [17:34] I understand your difficulty [17:35] I'm pretty sure the merge code doesn't have a way to work "lazily" and only extract texts for files that it is going to think of as modified [17:35] It might be possible to patch it in [17:35] as a "LazyWorkingTree" or something like that [17:35] jam: http://paste.ubuntu-nl.org/45130/ [17:35] jam: right, i wondered about that [17:36] jam: TreeTransform seems to hit the disk reasonably directly though, which worried me for this approach [17:37] yeah, but I think you could hide the real working files [17:37] Let me look at the code for a bit [17:38] jam: thanks [17:40] mwhudson: it depends on how much you want to spend writing up a LazyWorkingTree, but it seems possible [17:40] you would still need to hit disk [17:41] but the idea is you would create an object that doesn't extract text contents until it needs to [17:41] and it could track the list of files which were modified [17:41] i don't care about hitting the disk [17:41] mwhudson: I could certainly help walk you through it if you want. [17:41] i care about doing O(changes) rather than O(changes+tree) work [17:42] sure [17:42] jam: how much work would you expect this to be? [17:42] I'm saying more: how much time do you want to spend coding this up :) [17:42] I'm actually thinking it wouldn't be that much effort [17:43] You only need to override a few key places [17:43] i dunno, i don't want to spend a week on it [17:43] but a day is probably just about reasonable [17:43] so some quick pointers... [17:43] you wouldn't use "target_branch.create_checkout()" obviously [17:43] instead you would init a new WT type [17:43] on that branch [17:44] and then you would override WT.get_lines() or it looks like you might need to also do WT.get_file() [17:44] (I don't know for sure why TT uses get_file().readlines() rather than get_lines() [17:44] might just be hysterical raisons) [17:44] i should subclass WorkingTree ? [17:45] mwhudson: I think subclassing WT4 might be a good way to go [17:45] bzrlib.workingtree_4.WorkingTree4 [17:45] as it has better "diff" code [17:45] All you are really adding is a list of things that have been modified [17:45] so your 'get_lines()' implementation knows to read from disk [17:45] rather than going to the repository. [17:46] (and get_file_sha1() also needs to be overridden) [17:46] and probably get_file_size() [17:46] mwhudson: If you want, I could probably try hacking something together [17:48] jam: that would be cool [17:48] I'll give it an hour or so and see where I get [17:48] jam: awesome [17:49] actually, it almost fits in with an idea Robert had [17:49] to make commit/diff/etc extra fast [17:49] by requiring the user to explicitly mark things changed [17:49] It just goes an extra step and doesn't bother creating the other files === cprov-lunch is now known as cprov-away [18:26] mwhudson: so you want a tree where the user can't introduce changes, only merges can. [18:26] lifeless: what i want is described by the docstring of the function [18:27] lifeless: but yes, something like that sounds like a reasonable approach [18:27] mwhudson: which function? [18:27] lifeless: http://paste.ubuntu-nl.org/45130/ [18:32] jam: I think a working tree is the wrong approach for mwhudson's request; I'd look at subclassing merger myself [18:32] jam: then passing in two revtrees [18:32] so the output instead of being back into a working tree would go forward as iterable output [18:32] lifeless: you would have to keep the contents of all modified files in memory for the full length of the merge [18:33] jam: nope [18:33] i think I see where you are going with it [18:34] but I don't think Merger is really cleanly capable of it [18:34] This is a design I prepared earlier FWIW :) [18:34] which reminds me [18:34] what's the relationship between Merge3Merger and Merger ? [18:34] merge logic [18:34] what to do when you have files that need to be combined (merged) [18:35] i am perpetually surprised by the fact that there is no subclass relationship here [18:35] mwhudson: me too looking at it [18:35] still; patches kthxcontribute [18:36] I believe Merger is the 'metaprocess' [18:36] and it takes a merge_type as a helper class [18:36] which at the least are poorly named [18:36] lifeless: i don't feel competent in this code [18:39] ok, time for some pb luv [18:43] hi everybody. [18:44] LarstiQ: ping [18:44] hi jml [18:45] I think I am going to spend some time making Trial able to run the bzr tests. [18:50] aren't you on leave ? [18:50] lifeless: yes. [19:07] ok, so if you can trick trial into running on the return value of bzrlib.tests.test_suite(), rather than doing discovery then it works quite well. [19:07] modulo our TestResult objects not supporting TestSkipped and TestNotApplicable. [19:08] hello. is there a way to push just individual files into other branches? [19:09] Not really.. "individual files" don't really exist in discrete form. [19:09] A branch isn't a collection of files. It's a collection of revisions. [19:09] Revisions contain changes to (additions/modifications/renames/deletes) files. [19:09] well [19:10] i have a bunch of different branches and in each one, i want to take some files out of those [19:10] (As compared to the RCS/CVS/SVN view of the world, that says files exist, and revsisions exist within files) [19:10] and put them into a branch called stable [19:10] because a bunch of different developers have all been working on different things [19:10] Do you want to preserve all the history so far, or just "carry on" from here? [19:10] and each of them have *some* files which i want [19:11] 'bzr merge branch/FILE' will merge just hat file. [19:11] lifeless: ah! interesting [19:11] we don't currently remember later that we did that. But it will work. Also works for directories. [19:11] well i mean, how is this "done right" ? [19:12] i got a bunch of different people who are working on different branches.. [19:12] the guy doing Feature A has old files for Feature B [19:12] the guy doing Feature B has new files for Feature B and old files for Feature A [19:12] so in stable, i want the new files for Feature B from the Feature B guy [19:13] and the files for Feature A from the Feature A guy [19:13] bagueros: oh, but you want to merge the full FeatureA and FeatureB branches, one after another, or just specific changes from them? [19:13] I don't want Feature B guy's old Feature A files to overwrite Feature A guy's new Feature A files [19:13] you know what i mean? [19:13] yes [19:14] bagueros: oh, just bzr merge [19:14] if you merge FeatureA, and then merge FeatureB, all changes will get merged. [19:14] we clearly need some documentation improvements here [19:14] indeed [19:15] and merge will figure out who has the latest version for each file [19:15] and use that one? [19:16] yep. even if both developers touched the same file, but different parts of it, will do an intelligent merge and combine both changes. [19:16] bagueros: it will integrate the changes made. [19:17] and trial misses exactly 777 tests. hmm. [19:17] ok [19:18] jml, what's trial? [19:19] dato: a unit testing framework that twisted uses. [19:19] ah, okay. [19:23] which is the number of tests that I have in my various plugins :) [19:36] jml: do you know about "bzr selftest --list-only" ? [19:36] It might make it easier to figure out what is and isn't being found [19:36] You could use "bzr selftest --list-only | sort" and compare the output [19:37] jam: I didn't know about that -- thanks. [19:41] hi [19:41] wasn't there a «bzr cdiff» option some time ago, or did I dream that? :P [19:41] RainCT: from bzrtools [19:41] ah ok, thanks [20:02] jam: ping [20:02] jam: I'd like to sanity check a refactoring goal with you. [20:02] I want to make pb a bit simpler. heres how I think it might look [20:05] firstly, I want to decouple 'progress' and 'display'. Nesting is about progress not display. So I'm thinking of adding a Task concept [20:05] this will have message, current, total. [20:06] now, I don't think we care about estimating time for all tasks. Only the overall one. So there will be a subclass TimedTask that adds in the eta calculations etc. [20:08]