[00:12] hi folks, i branch a project from lp i made my changes, commited now i try to pull from lp and tell: [00:12] bzr: ERROR: These branches have diverged. Use the missing command to see how. [00:12] Use the merge command to reconcile them. [00:17] Indeed. You don't want to pull, in this case [00:20] so pull is not the way to update from lp [00:20] maxb, that is what i want, what i need to do? [00:21] "Use the merge command to reconcile them." [00:21] bzr merge [00:25] maxb, i dont have write permissions in lp that is not a problem? [00:26] no [00:27] bzr 101? - if i have a branch and merge from trunk, can i commit just those changes and not my own as yet uncommitted ones so that bzr status shows just my in progress changes and not everything? [00:28] No. bzr merge will remind you that your working tree has changes when you try to merge [00:29] Either commit or shelve your local changes first [00:29] Or branch your branch, merge in that, and pull the result back into your first branch [00:30] shelving may be the go. i want to keep current with trunk but am not ready to commit my in progress work [00:30] thanks [00:31] seems like a bit of a pain though. is the workflow i am wanting considered "unusual"? [00:32] coming from a svn world, it seems normal to do that sort of thing :-) [00:34] I use shelve a -lot- [00:34] To the point that when I was still being required to use CVS at one workplace, I wrote myself a cvs-shelve command :) [00:37] There's no real workflow difference from svn here [00:37] yes, it's a useful feature, especially with good merge support in the VCS. not sure how well it would work with CVS :-) [00:37] or, had you not ever committed since branching? In which case, pull, don't merge [00:38] no, i had committed. [00:38] with svn, you don't have to first shelve before updating from the central server [00:38] In svn if you wanted to merge from trunk whilst having uncommitted changes, you'd need to "shelve" the changes off as a patch file first [00:38] so to me there is an extra step with bzr [00:40] i've never had to do that with svn - i just update and all the changes from trunk come down and a "status" just shows my uncommitted changes as expected [00:40] wallyworld___: sure, but this is about merging not updating [00:40] wallyworld___: merges change your working copy [00:40] (in both bzr and svn) [00:41] wallyworld___: If you were in the same situation in bzr, you would pull, not merge, and you'd get the same result [00:41] would you still pull even if you had uncommitted changes? doesn't it complain? [00:42] it doesn't [00:42] for the same reason svn doesn't [00:42] ah ok. i thought that it did. sorry. [00:43] thanks for the input, much appreciated [01:02] Good morning. [02:12] hi spivvo [02:34] Hi poolie, I just had a bit of a tour of the wonderful world of generating sphinx docs from optparse. https://code.edge.launchpad.net/~spiv/bzr/html-cmd-help/+merge/36244 [03:00] poolie: I didn't get to loggerhead today, just FYI. Perhaps tomorrow or Thursday. I did start to do some research yesterday, though. [03:01] poolie: Just wanted to let you know so that I wasn't going dark on anything. :-) [03:05] Anyhow, I'm out for the evening! :-) [03:05] Night. :-) [03:07] hi folk i have a question i can versioning my documents with bzr? [03:11] ovnicraft: yep! [03:12] spiv, so bzr can show in 'rich text' the diff ? [03:12] No, if it's not plain text bzr will just say "binary file changed" for that file in the diff. [03:12] spiv, assuming an Ooo doc from writer is a zip bzr knows how works with work? [03:12] And similarly it can't automate merging. [03:13] i need something like that [03:13] So bzr can happily store the different versions of binary files, but it can't help you compare them. [03:14] (Unless someone writes a bzr plugin for that kind of file) [03:23] spiv, wow, that specific check for '1.9' is gross [03:32] Hmmm, a bzr plugin for diffing archives would be interesting; especially if you could treat archives as folders. [03:40] meaning ppa archives? [03:40] or zips? [03:49] poolie: Meaning zips [03:51] There are plenty of file formats (including ODF) that are just zips of some files; being able to diff them would be handy. [03:52] Actually, being able to merge them would be even better. [03:52] The hook point for merging them already exists. [03:53] So it's just a simple matter of writing the plugin then ;) [03:53] Actually I thought it might be more fun to write a plugin to allow merging of GIMP/Photoshop formats. [03:54] As long as the changes are on different layers you can actually do a conflict-free merge. [03:55] Heh, that would be cute. [03:55] heh [03:55] i don't know how often that happens but it would be cute [03:55] But that's just a blue-sky project until I knock the documentation bug count down to zero. [03:55] you know showing conflicts as layers might even kind of work too [03:55] jbowtie: thanks so much for all your patches [03:55] you're getting through them at a great rate [03:55] poolie: Ooh, layers called THIS, BASE, and OTHER? :) [03:57] Well, artists are always complaining about not being able to version using a DCVS. But the collaboration workflow actually usually has them touching different subfiles within some massive binary zip. [03:57] *nod* [03:57] poolie: It's for my own sanity as well; hate looking something up and having it be wrong. [03:58] So being able to support layers or (in the case of Blender, animations versus meshes versus textures) would address some of those artist issues. [03:59] But that involves working with the various free software art tools to come up with useful diff/merge/conflict resolution. [03:59] Right. [03:59] It would be a neat project. [04:00] It would possibly also encourage us to keep improving our performance when dealing with large files... [04:01] spiv did my 'scripts' branch fail? [04:02] poolie: text conflict in NEWS... [04:04] huh [04:04] poolie: but not when I try locally with news_merge enabled [04:04] So I guess PQM still doesn't have news_merge working :/ [04:05] spiv: probably need to upgrade bzr [04:05] poolie: https://pastebin.canonical.com/37408/ is how news_merge was configured on PQM [04:05] spiv: it runs from a source tree [04:05] hysterical raisins [04:05] lifeless: the RT had step 0 as checking that bzr was already upgraded [04:05] spiv: the one in the source tree? [04:06] But yes, there's enough confusing wrinkles in the PQM deployment that this sort of thing never goes smoothly :( [04:06] lifeless: I don't know, I don't have access to see [04:07] lifeless: it was RT #41382, if that helps you [04:22] spiv, i'll update and repush it [04:23] poolie: Hmm [04:23] poolie: it's kinda nice to have the test for whether news_merge is working ;) [04:23] But not worth holding up your branch unless that's likely to be fixed soon. [04:24] I'm not sure what to do about it... I don't feel I have enough information to construct an RT to correct whatever is wrong. [04:25] And I assume LOSAs would rather not receive "it doesn't work, please fix" RTs any more than we like them as bug reports :) [04:26] Making any changes to the PQM deployment always feels about 10x more frustrating than seems reasonable :/ [04:26] iirc it's a useful but not critical patch [04:26] so, there's no rush [04:26] Right. [04:27] hm [04:27] i'm suspecting we might be better off prototyping tarmic [04:27] hi [04:27] *tarmac [04:27] does the BZR_EMAIL for committer id need to be "email shaped"? [04:27] or can it be any string [04:28] thumper: andrew@Aihal:/tmp/a-branch$ BZR_EMAIL="any string" bzr ci -m "Foo." --unchanged [04:28] Committing to: /tmp/a-branch/ [04:28] Committed revision 1. [04:28] spiv: is there an expectation that it is email shaped? [04:28] will there be a future tightening of the constraint? [04:28] could there be a future tightening/ [04:28] ? [04:29] I don't think so. [04:29] thanks [04:29] I'm pretty sure there'd already be not-email-shaped commits in the wild [04:29] e.g. imports from CVS [04:54] Just found out Rob Collins is also from NZ. I wonder how many mutual acquaintances we have? [04:59] Sorry, guys, that was meant for Twitter. [04:59] jbowtie: that's ok [05:01] You say that now, but next time it'll be something far more embarrassing. :) [05:01] jbowtie: at least IRC doesn't spread XSS attacks quite so well [05:02] jtv: I'm safe until they target Gwibber. Then all my networks are toast. [05:03] * jtv gets the butter and prepares to wait [05:07] it's funny how much twitter reinvents irc [05:08] If I push a fix to a branch that has been proposed for merge, do I need to do anything else for reviewers to take note of the fact? [05:09] uh kinda [05:09] it shows up on the web page [05:09] normally that's enough [05:09] jbowtie: the diff on the web page will be automatically updated, but the reviewers won't get notified [05:09] if you want to specifically ask, you have to mail the mp [05:09] So add a comment if you want to to draw attention to the update. [05:10] spiv: You answered the question before I finished typing it. [05:10] You can also resubmit, which starts a fresh review. [05:11] For small changes in response to a review so far I'd usually just add a comment. [05:14] i'm transitioning my brain from svn to bzr right now.. what's the bzr equivalent of svn postcommit hooks? i push from my laptop to a server, want the server to execute something when i push to it [05:14] Ugh, my html-cmd-help fix broke test_help [05:15] spowers: there's a post_change_branch_tip hook in the API [05:16] Unfortunately you can't just put a command in a configuration file, but you can use it by writing a simple plugin. [05:18] (Hmm, ISTR to recall I had an prototype of a plugin that could run a command from a config file when that hook fires, I should dig that up) [05:18] it sounds like people have found other ways to solve the same problem? [05:20] after i push to the server, i need to have it kick apache [05:20] Well, many people just want email notifications, and there's already a plugin for that. [05:21] For everyone else... well, as I say, it's not difficult to write a simple plugin. [05:21] ok, i'll look into that [05:21] there are client side hooks too, right? [05:22] Yes, the exact same ones. [05:23] that's probably all i need.. i have ssh keys set up, so i could just flip a switch via ssh [07:27] good morning vila [07:27] poolie: morning poolie ! [07:27] hi all ! [07:31] poolie: quick chat ? [07:32] sure [09:11] vila, i wonder if a registry is a good fit for this because to me they seem very oriented to looking up a single thing by name [09:11] whereas this is more of a multiple dispatch deal [09:11] however i agree, we probably want to somehow combine various relevant sources [09:12] right, so the idea is that the registry will change the way we get our config objects from calling BranchConfig or GlobalConfig explicitly to calling get_config('branch') [09:12] from there it becomes possible to define what a branch config is or what a tree config is without being forced to create a new class [09:13] the idea of multi-level configs is that if one config doesn't define a variable, we fall back to another config [09:14] this should scale pretty well for the user once we provide a 'bzr config' command that will tell *where* a variable is currently defined === spike_ is now known as spikeWRK [09:14] and also *which* config files are involved for a given variable [09:15] this file <-> variable relationship may need to better specified too, as currently *some* variables should not be overridden [09:16] I thought we already had multi level configs [09:16] via a composite pattern [09:16] lifeless: we have [09:16] good good [09:17] There's also some code in bzr-pqm along those lines, IIRC [09:17] I'd like to replace the composite approach by a more generic list based approach where you just say branch.conf > locations.conf > bazaar.conf [09:18] --ignore-local needed it for some reason [09:18] vila: it's been a while, but that sounds rather like the code in bzr-pqm [09:18] to allow tree.conf > branch.conf > repo.conf > locations.conf > bazaar.conf and allow plugins to put whatever they see fit wherever they see fit [09:19] but we need some way to also define that a variable *cannot* be redefined in some cases [09:19] vila: http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel/annotate/head%3A/pqm_submit.py#L198 [09:20] spiv: exactly, thanks for finding the relevant url so fast ! [09:20] vila: see #L226 for where it is used [09:21] so, one example of a variable that we don't want to redefine may be the stacked_on url which is defined server-side (may be not the best example but you get the idea) [09:21] vila: I'd wanted to get that put into core bzrlib, but lacked a motivation other than "it'd be nice" [09:23] There's also some security concerns, in that using an untrusted branch shouldn't be able to e.g. configure bzr, or a bzr plugin, to rm -rf /. [09:23] spiv: yeah, exactly, you needed a new class *and* various calls to achieve: get_config('branch') [09:24] spiv: right, that should be defined at the *variable* level [09:24] Yes, probably. [09:24] spiv: may be not specified for evey variable but what I have in mind is the ability to *declare* a variable in config and use various decorators [09:25] Sounds like a good approach to me. [09:26] in config or elsewhere, in fact, the discussion with poolie was to make it trivial to turn any constant in the code base into a config variable [09:26] vila: actually the motivation I did have for maybe putting StackedConfig in core is it possibly would simplify bzrlib/config.py a bit, because the general facility it provides might simplify some hard-coded "this config asks this other config" logic. [09:26] add the '-O' option from the command line and we get the ability to try various tricks [09:27] spiv: yup [09:32] ok, so I'll see what first step I could propose, any thoughts ? A first 'bzr config' showing the variables values and where they are coming from, plus a way to set a new value or delete a variable may be ? [09:34] argh reboots needed everywhere, bbiab [09:34] The first half of that sounds like a fairly small and worthwhile step, the second half ("plus a way to set...") sounds a bit large, perhaps. [09:35] well, no, not yet, but soon [09:35] spiv: ok [09:35] But try it and find out :) [09:35] (That's just a quick reaction, not a deeply considered opinion) [09:35] Hmm, it's getting late. [09:36] * spiv -> dinner [09:36] spiv: enjoy ! Thanks for feedback [10:17] Bug #636712 says we shouldn't be recommending sftp [10:17] Launchpad bug 636712 in Bazaar "docs shouldn't recommend sftp (affected: 1, heat: 41)" [Medium,Confirmed] https://launchpad.net/bugs/636712 [10:19] isn't sftp recommended because its the most secure way to use a server without setting anything up on the server? [10:19] That implies that in the mini-tutorial, we should be telling people to set up a bzr+ssh server. [10:19] sftp is not recommended because it is inefficient [10:19] compared to what? [10:19] bzr+ssh, for example [10:19] only a smart server, which isn't introduction stuff [10:20] bzr+ssh needs bazaar on the server, sftp doesnt [10:20] Glenjamin: that's a different issue [10:20] Which transport is recommended for general use [10:20] and which transport is easiest to setup and secure [10:21] i quite like bzr+https personally, as the web server has plenty of ways to layer auth [10:21] Well, we want to make sure people understand that sftp is not the best option. [10:21] a general transport comparison page would be cool [10:21] and then mention the comparison page in the tutorial [10:21] Glenjamin: IMO, that's still significantly harder to set up than bzr+ssh [10:21] also, I heard it's less efficient [10:21] yes it is, but its more flexible imo [10:21] but I don't know why [10:22] Which could be reduced to just a note anywhere we mention sftp. [10:22] i dont trust file ownership with multi-user bzr+ssh, but maybe thats just me [10:22] that's just you [10:22] bzr+ssh will be better than sftp [10:22] if you don't trust operating systems permissions, you have a big problem [10:22] Probably bad memories of early svn servers. ;) [10:22] sftp masks out bits needed for multi user managed directories. [10:23] (on the server) [10:23] i understand them, they just tend to break [10:24] such as when other people poke around on my servers [10:25] The mini-tutorial doesn't explain how to set up a SFTP server, just says "if you have access to one". With bzr+ssh we could look at linking through to the setup instructions. [10:26] Really, what's the best experience for the complete newbie who wants her own server? [10:26] launchpad! [10:26] Launchpad is the best option, unless you're setting up a corporate server. [10:27] We already have launchpad covered in the mini-tutorial. [10:27] and if you're setting up a corporate server, you don't need the short version, you need to know the details [10:28] I agree - but setting up ssh is easier than setting up http. And sftp is easier still, which is probably why the docs originally went with that. [10:29] However sftp is a bad example because performance will kill you when you go to import your svn server. [10:29] So I'm thinking - give bzr+ssh as the main example; with a note about the alternatives (bzr+http and sftp) [10:30] Of course in the user guides we have all the details anyway, it's just the tutorial examples I'm thinking about. [10:31] Setup isn't so bad, it's "apt-get install bzr sshd" (or your distro equivalent) on your server then you can push with bzr+ssh. [10:34] poolie: You filed the bug, any opinion? [10:45] The big sticking points for corporate servers are access control and organization of many branches [10:47] i'd say there's plenty of ways to do access control, but i'm not aware of a good entry-point for restricting branch organisation [10:48] maxb: I know, I handle Subversion, TFS, and Bazaar servers at my current employer. [10:48] what method do you use for the bazaar repo / branch permissions? [10:49] We use ssh. If branches need different permissions we put them in different locations on disk. [10:50] everyone uses their own ssh login, and shared branches are done via groups? [10:50] We could also split branches across different servers if needed. [10:50] Correct. And I handle merges to trunk. [10:51] Normally we do feature and bug branches, so there's not too many shared branches, I create those manually. [10:52] ah, so you set the permissions for the shared branch explicitly [10:53] Sort of, I have directories corresponding to our usual groups and branch into those locations so they inherit permissions. [10:53] bzr+ssh://my.server/editorial/feature-X [10:54] i've got two different repo setups here - both use a wrapper to manage access/permissions and have all branches owned by the same unix user [10:54] This is the major sticking point to corporate bazaar, I think - everyone has to reinvent a variant of this [10:54] it's almost as if we need a mini-launchpad :-) [10:55] In theory you can set up your own launchpad. [10:55] I haven't had a machine to play with though. [10:55] i'm pretty happy with the latest approach i've done: loggerhead proxied through apache and bzr+https via mod_wsgi+apache at the same location [10:56] and then I use apache's access controls to limit access (using ldap) [10:56] That's pretty much what we do with the Subversion servers, probably would consider it for bzr if admin load increased too much. [10:57] jbowtie: Yes, but first you need to invest an awful lot of time in it replacing all the images [10:58] http://dpaste.com/247244/ [10:59] hi [10:59] maxb: True, but with open source only one person really needs to do that work once. [11:00] ish, subject to merging ongoing development [11:00] well you could abstract out the branding [11:00] and get it back upstream [11:00] bzr fails to install on debian lenny (from backporst) [11:00] backports [11:02] http://dpaste.com/247244/ [11:02] pycentral: pycentral pkginstall: error byte-compiling files (735) [11:03] maybe it needs python 2.6? [11:03] millun: I'm having a quick look now to see if there's anything obvious [11:03] cheers [11:04] python on lenny is 2.5. my localhost py is 2.6 [11:08] millun: Do you have multiple versions of Python installed on that machine? [11:08] no [11:08] maybe not [11:08] i'll check [11:09] is there a way to get a more verbose error? that one's a bit vague (i'm not too familiar with dpkg) [11:09] millun: we are currently releasing 2.0.*6* would you mind trying to push the upgrade on the debian side ? I don't know whether this will address your immediate problem but at least you'll get the fixes done since 2.0.3 [11:10] oh ok. i'll ask the guy who decides [11:10] millun: and I should have said: we are leasing 2.0.6, 2.1.3, 2.2.1 and 2.3b1 the first three being stable releases [11:11] millun: I don't want to make your life harder (quite the contrary) but it's a bit deceiving to use a packaged distro if you can't get the last available stable updates :-/ [11:14] fullermd: Quick FreeBSD question, I do regular 'updports.sh ; portupgrade -a' (as in once every full moon) and there is a number of patches mentioned there. ~2400 seems.. hard to relate to the number of packages updated, is "patch" here referring to a CVS commit ? What's the level of detail ? [11:14] vila: packages.debian.org shows 2.0.3 in lenny-backports; maybe we should bounce a reminder to their maintainer team? [11:14] jbowtie: yeah, I did that, but no response so far [11:15] jbowtie: but may be I didn't ping the right ones ? What will *you* do ? [11:16] jbowtie: or rather, if you know what to do, please do :-) And put me in the CC :-) [11:16] vila: I'm looking at their mail archive right now to see what's been going on. [11:16] I'm not familiar enough with debian to know whether they are still interested with our 2.0 updates or not... [11:17] jbowtie: great [11:17] vila: Sure, consider it an audition for my BSE application. :P [11:17] jbowtie: err, which one ? url ? [11:17] jbowtie: hehe, couln't hurt, but I'm not the one taking the decision here ;-) [11:17] http://lists.alioth.debian.org/pipermail/pkg-bazaar-maint/ [11:17] right, so my mail should be there [11:19] I see it, they apparently have no spam filter on that list though, judging from the state of the archive. [11:21] backports.org is not technically an official Debian service yet. [11:21] Also, it's a backports service, so if anything, they might as well update it to 2.2.1 [11:22] maxb: who should decide, or better, act here ? [11:23] vila: Looks like jelmer is probably the best person to talk to, he's listed as a maintainer and is active on their list. [11:23] jbowtie: hehe, yeah, jelmer is great, but looks a bit overbooked, so who is the backup there ? ;-D [11:25] vila: Anyone who wants to volunteer their time. Non DD/DMs need to act through the Debian mentors. Reminding the person who last uploaded the package to lenny-backports is a good idea [11:25] backports.org is not technically an official Debian service yet. [11:25] Ooops, now it is! [11:26] maxb: ok, DM == Debian Mentors, are you one ? I really need to start somewhere... [11:26] Also, packages are supposed to hit testing before being considered for backports, so at the moment, it's 2.1.2 that's eligible [11:26] DM == Debian Maintainers [11:27] No, I have no Debian official affiliation at present [11:27] gah, so who are the mentors ? Any DD or DM ? [11:27] Though one of these days I ought to re-investigate my potential for DM and/or MOTU [11:28] maxb: so, re-reading http://packages.debian.org/search?keywords=bzr , you mean 2.1.2 can go from testing to backports ? [11:28] maxb: can 2.2.0 go from unstable to testing ? [11:29] No, the freeze is on [11:29] 2.1.2 can go to backports if someone does stuff according to http://backports.debian.org/Contribute/ [11:29] freeze for (sorry for the idiotic questions but as I said I ahve to start somewhere :-}) [11:29] pre-release freeze for squeeze [11:30] maxb: which means it will become stable ? [11:30] eventually [11:30] vila: I'll fire off some emails to the lists in about 10 hours to see if there are any DD's hanging around, maybe we can get jelmer to give us some names. [11:30] jbowtie: ok [11:30] jbowtie: thanks [11:31] maxb: let see, where can 2.0.6 go (in debian context) ? Nowhere ? [11:32] correct [11:32] 2.1.2 goes to backports [11:33] 2.2.1 to unstable ? [11:33] or should we just target 2.2.1 to backports ? [11:34] maxb: quite different than Ubuntu where we want 2.0.6, 2.1.3 and 2.2.1 deployed and 2.2.1 and 2.3b1 in the ppas right ? [11:35] or may be not that much, debian being closer to what we do for ppas ? [11:35] The key difference is that Ubuntu has an -updates pocket [11:36] vila: I'll also email the debian-backports list to see if anyone wants to help sort this specific issue. [11:36] hi all. [11:37] vila: Debian has its own concept of updates, but they're limited to security and dire emergencies [11:37] mgz: _o/ [11:37] jbowtie: good idea [11:40] maxb: how do we apply that to our releases then ? [11:42] We put the latest stable into Debian unstable, except when there's a freeze on. We consider helping update stable-backports from testing. [11:42] wow http://backports.debian.org/Contribute/ seems a bit intimidating at first... I may to filter a bit about what we already do in bzr [11:43] maxb: ok, so 2.2.1 -> unstable except not, 2.1.2 to backports then right ? [11:43] yes [11:45] and then... 2.2.x to unstable after the freeze or 2.3.x depending on when it occurs [11:47] in summary we push only two of our series and help our older stable releases to progress in backports unless some serious bug is considered for... testing ? [12:04] thanks guys, upgrade resolved the issue [12:08] i forgot if i should do checkout or branch [12:09] depends what you're getting [12:09] millun: Checkout creates a bound branch (commit has to succeed at server before it is applied locally) [12:10] if you want a copy of a remote branch that's easy to update, i'd use checkout [12:10] if you're going to make local changes, then branch [12:10] millun: Branch creates an unbound branch (commits are local, use push and pull to interact with server) [12:11] i have a php project, i want to run it on a dev server [12:12] some minor changes in config files will occur [12:12] config files which change should be outside of version control, if generally use checkout for a deployment [12:12] s/if/i/ [12:13] i know i was using bzr pull command [12:13] millun: If you were using pull, then you would have used branch instead of checkout. [12:13] did checkout now [12:13] should be goo [12:13] d [12:14] so now i will be using bzr update or like? [12:14] Correct, or you can use bzr unbind and then use bzr pull. [12:15] ok [12:15] thankls [12:15] Right, I'm off, time for bed in my time zone. [13:23] when using bzr-svn with an existing maven'ised svn project is there something i can use in the scm section of the pom.xml file so that bzr tools will be launched locally instead of svn tools? [13:29] I don't think so [13:33] millun: when you say " upgrade resolved the issue" which version do you use now ? [13:49] Hello [13:49] I'm looking for a way to store the current revision number in a file [13:50] The file itself has to be commited with that revision [13:50] How can I achieve that ? [13:50] That feels wrong [13:51] I want the revision number to be available in any export of the branch, why does it feel wrong ? [13:52] To be pedantic, that's a different requirement to wanting the committed text to have the revision number :) [13:52] * spiv -> bed [13:52] ploum: because a revision content should be fully known before giving it a revision-id [13:52] ploum: may be you're searching for 'bzr version-info' instead [13:53] vila: Well, actually, you can know the revno that a revision you're about to commit will get, so it's doable :-) [13:53] vila: I'm already using version-info [13:53] maxb: I went for the simplest explanation, there is still a chiken and egg problem there [13:53] I think a better solution would be a trivial script that wraps bzr export and bzr revno [13:54] vila: I agree it's not a very nice option, but I don't see any chicken/egg problem involved. [13:54] maxb: how can I achieve that other than a "current+1" ? (that I don't want to avoid doing +1 when the commit fail (because it is empty) [13:54] ploum: then what are you trying to achieve exactly ? [13:55] sorry, this is not related to export, (I'm confused by another problem) [13:55] current+1 is the only way you can predict the revno of a future revision [13:55] But, I second vila, what are you trying to achieve exactly ? [13:56] vila: I'm working in a very large SVN tree including multiple module. As I work only on a small part (one module), I use bzr-svn to work on that very small part. People working with the whole tree want to know exactly what is the "internal revision" of my module. [13:57] Bzr keep its own revno so it's fine [13:57] for example, my revno 5 is the rev 134 of the SVN [13:57] and I want to have a file, in that tree, that contains that internal revno [13:57] hrm [13:58] I currently write bzr revno [13:58] maybe simply revno+1 could be enough ? [13:58] ha, so you'd like people pulling from your branch (even indirectly) to get what your consider to be the revno, but it doesn't have to be the bzr revno, just an incremented value (for appropriate values of incrmented) right ? [13:59] the problem with 'bzr revno[+1]' is that it would be wrong if you uncommit for example [13:59] vila: more or less. I want it to be the bzr value so when they ask something, I can quickly revert to that number [13:59] vila: indeed [14:00]