pooliejml, hm, that doesn't seem to exist00:09
jmlhush, I'm being excellent.00:09
=== bob2_ is now known as bob2
=== bob2 is now known as Guest58725
jmlpoolie, :(00:10
jmlpoolie, I can't find it on Launchpad. Maybe I made it all up.00:11
jmlI distinctly remember blogging about it.00:11
pooliei remember you telling me00:11
spivArray['hosted', 'mirrored', NULL, 'remote'])[Branch.branch_type] ?  Surely proper SQL style would involve a table join ;)00:11
=== Guest58725 is now known as bob2
pooliespiv thanks for flagging the issue with 2.0 in https://code.edge.launchpad.net/~jameinel/bzr/2.0.4-unregister-mem-trans/+merge/1698000:17
pooliebut i think you should actually have bounced it00:17
spivpoolie: hmm, ok00:19
poolieto me the benefit is nonzero but small00:20
pooliedo you agree?00:20
spivpoolie: I think either way will be fine, really.  In absolute terms the risks and rewards for 2.0 are both very low.00:20
pooliethe worst that's likely to happen is test suite breakage i suppose00:21
spivI don't feel strongly, so I went with trusting jam's judgement.00:21
poolieit's possible there will be some gc-related effect00:21
pooliewell, that is a good default00:21
spivIf you feel more strongly than me, please add a review ;)00:21
pooliei did00:21
pooliei'm just wondering if we should either discuss or clarify the 2.0 guidelines00:21
* poolie looks00:22
spivIt's the sort of thing I'd be more relaxed about at the start of 2.0's life, I think.00:22
pooliei think for the stable branch00:23
pooliehaving low risk and low reward is not enough00:23
poolieit needs to have a high reward00:23
pooliebecause it's not just the risk, but also that a larger diff is harder to push through an SRU00:23
spivI think as time goes on the rewards for doing things to a stable branch tends to go down (less and less users, and the users that it has are happy or they would have jumped to the next branch), but the risks don't really drop in the same way.00:24
spivBut also it does help us to keep the delta between stable and trunk minimal.00:24
poolieif john really wanted to do it in 2.0 i wouldn't necessarily veto it00:24
pooliebut i would want at least a specific rationale for putting it in00:24
pooliethat's good too00:24
pooliethe thing where the delta is most going to matter, i think, is api changes that will limit your ability to merge patches across00:25
pooliebut of course they're also harder to put into the stable branch00:25
pooliei suppose one could do additive-only api changes00:25
poolieand then do the deprecation/removal of the old api, if any, in trunk00:26
spivYeah.  Although reducing superficial conflicts from e.g. changing "MemoryTransport" to "memory.MemoryTransport" is nice too... that's not a big deal if there's just one, but multiple overlapping superficial conflicts can be a significant hassle to fix.00:26
pooliespiv, how about something like http://pastebin.ubuntu.com/353217/00:39
spivpoolie: +100:42
bendjHi.  Is there any particular (dis)advantage to bzr-managing a local dev box + a remote svr using bzr's sftp upload/checkout capabilities, versus mounting the remote server locally via sshfs (fuse over ssh)?00:58
lifelessbendj: better to use bzr+ssh/sftp01:00
igcthanks jml!01:06
bendjlifeless: Why 'better'?  Are there specific features capabilities that are available with one approach, but not the other?  sshfs mounts, in general, are much more handily managed locally ...01:07
lifelesssshfs mounts present a very odd picture of the latencies involved01:08
lifelessand don't really act like local resources - for instance file locks won't work.01:08
lifelessbzr+ssh urls will perform /much/ faster01:08
jmligc, np. it was fun to get my sql ninja on.01:09
jmligc, I just wish that turning an SQL query into a Launchpad page was less work.01:10
igcjml: :-)01:11
bendjlifeless: Huh, I was pretty convinced that file locks over ssfs ARE supported.  or do you mean bzr's file locking, in particular?  really surprised to hear bzr+ssh is "much faster" ... i mount all over the web via sshfs, and have never really seen performance issues.  then again, admittedly i have NOT benchmarked.  hmm.  worth investigating & learning more, sounds like ...01:14
mwhudsonjames_w: hello01:36
mwhudsonjames_w: how stable do you regard the BaseRecipeBranch api in bzr-builder to be?01:36
james_wmwhudson: hi01:38
james_wit can be as stable as you like :-)01:38
james_wI can offer guaranteed API stability if that's all you are looking for01:38
james_wbut that may mean new APIs for new things, so it depends on why you are interested I guess01:39
mwhudsonjames_w: i'm writing code that translates RecipeBranch &c objects into database objects and back01:39
mwhudsonif new stuff appears in bzr-builder, this code will have to change01:40
mwhudsonno way around that in any case01:40
james_wit sounds like API stability isn't the issue as such01:41
mwhudsonno, i guess not01:41
mwhudsondata structure stability01:41
james_wis holding off landing things until LP is ready a better solution?01:41
james_wwe are going to want to make some data structure changes, but they will probably come with recipe format changes, which may give us some flexibility01:42
jelmerhi mwhudson, james_w01:43
james_whi jelmer01:44
mwhudsonjames_w: i wouldn't wait on lp for stuff really01:44
mwhudsonjames_w: i can always refuse to have anything to do with formats > 0.201:44
mwhudsonwhich is probably a good idea in any case01:44
james_wjelmer: how's your flight looking?01:45
james_wmwhudson: that's what formats are there for :-)01:46
mwhudsonjames_w: indeed01:46
james_wonce I see some of your work next week then I'll have a better grasp on what your needs are, which should help01:46
james_wI'm not out to break LP though, so I'll try and make sure that changes that I make are accommodating to you01:46
mwhudsoni guess all i'd like to avoid, or at least know about, are pending fundamental refactorings in how recipes are represented01:47
james_wthat's easy enough to do01:47
james_wnothing pending in that part currently, except talk of inheritance01:48
mwhudsonjames_w: recipe inheritance you mean?01:48
mwhudsonwell, i'll deal with that when it happens01:50
mwhudsonat the least, it will be a format bump, right?01:50
james_wbut now, I must sleep01:50
james_wmwhudson: when do you arrive in Wellington?01:51
james_wor are you there already now?01:51
mwhudsonjames_w: probably only monday morning, or maybe sunday night01:51
mwhudsonjames_w: sleep well!01:51
james_wok, I'll see you then01:55
james_whave a good day01:55
jelmerjames_w: I'm flying tomorrow at 8 in the evening. What about you?02:00
jelmerjames_w: g'night02:00
* jelmer gets some sleep as well02:00
james_wjelmer: 9pm for me, fingers crossed02:00
mwhudsonwhere's the bug? http://pastebin.ubuntu.com/353256/02:40
mwhudsoni guess it's in find_branches02:40
mwhudsonheh ** 202:42
* mwhudson finds https://code.edge.launchpad.net/~ian-clatworthy/bzr-builder/fix-find-branches/+merge/1513702:42
chromakodehey #bzr, I would like to uncommit a merge, but restore the subcommits that were merged. is there an easy way to do this?02:45
mwhudsonchromakode: i'm not sure i understand02:47
mwhudsonchromakode: what commands did you run and what would you like to have done?02:47
chromakodemwhudson, unfortunately, someone on my team pulled from trunk, merged their changes, and pushed back to trunk, without proper review02:47
mwhudsonnote that if you just run "bzr uncommit" you'll get into a situation with pending merges02:48
chromakodeoh, really!02:48
mwhudsonchromakode: ah, that old fun02:48
chromakodeI didn't know that02:48
chromakodebefore the merge, there were 3 commits by a reviewer -- they're now wrapped up in the merge02:48
mwhudsonappend_revisions_only = True ftw02:48
chromakodeso, I didn't know that factoid... perhaps I can figure it out with that new knowledge02:48
chromakodewhat/where is that?02:48
mwhudsonin the .bzr/branch/branch.conf file02:49
mwhudsonlet me see if it's documented somewhere02:49
chromakodethank you!02:49
mwhudsonchromakode: hm, i found this https://lists.ubuntu.com/archives/bazaar/2008q3/046797.html02:50
mwhudsonchromakode: and "bzr help configuration" has some stuff02:51
mwhudsonbut first, you need to recover from the mess02:51
chromakodereading :)02:51
chromakodeyes. so, now I have 3 commits on my merge queue02:51
chromakodehow do I unmerge them?02:51
chromakodenote: there's also a commit on head *before* the merge that also needs to go02:52
chromakodethe log looks like:02:52
chromakode* bad merge02:52
chromakode* bad commit02:52
chromakodeI want:02:52
chromakode3 x * old commit from merge02:52
mwhudsoni think something like this02:53
mwhudsonbzr log --show-ids -l 4 and copy the revid of "bad commit" somewhere02:53
chromakodegot it02:53
mwhudsonthen bzr log --include-merges and somewhere near the top you should see the old commits that you want back on the mainline02:54
mwhudsonthat'll have a revno like 60.1.302:54
mwhudsonbzr pull --overwrite -r $revno .02:55
mwhudsonwill bring that bad to tip02:55
mwhudsonthen i think you can bzr merge -r revid:$bad_commit_revid .02:55
mwhudsonand commit that properly02:55
chromakodeI think that single pull --overwrite did the trick!02:59
mwhudsonwell, it will have obliterated the changes your teammate made03:00
mwhudsonbut looking back, perhaps that's what you wanted03:00
jmlif I do a merge that changes a whole heap of files, and then I accidentally edit some files before committing, is there a good way of finding out changes I made that weren't part of the merge?03:04
mwhudsonjml: do the merge in another copy of the branch, then diff -r branch:03:05
jmlmwhudson, that's a good idea.03:06
mwhudsonjml: or perhaps better, do the merge in another copy of the branch, commit it, and then pull from there into the version you made changes in03:06
jmlmwhudson, ooh, I like that.03:06
mwhudsonyou risk conflicts i guess, but they're probably ones you should know about03:06
=== mwhudson_ is now known as mwhudson
=== mwhudson_ is now known as mwhudson
chromakodemwhudson, back -- yes, that's exactly what I wanted03:21
chromakodemwhudson, they pushed it to their own branch before I obliterated them03:21
chromakodethanks very much for the help mwhudson. you really saved me a lot of time. :)03:21
mwhudsonchromakode: cool, np03:22
* mwhudson wonders if bzr.dev r4943 will break launchpad03:45
=== abentley1 is now known as abentley
PengLooks like bzr+http and Loggerhead don't use it, so I should be okay.03:49
* igc lunch03:55
=== oubiwann_ is now known as oubiwann
PengYeah, they're ok.03:57
poolieigc, nice work on the imports!04:02
lifelessspiv: I really want to fix the exception handling in     def _run_pre_change_branch_tip_hooks(self, new_revno, new_revid):04:49
lifelessspiv: are you still attached to it?04:49
lifelessspiv: by fix, I mean delete.04:49
spivlifeless: lemme look again04:49
lifelessspiv: please do - and compare to '_run_post_change_branch_tip_hooks' right above it.04:49
spivlifeless: so the main thing I guess I care about is that TipChangeRejected is still passed through in such a way that a server-side hook can cleanly transmit it to the client.04:50
spivlifeless: and I doubt you'll break that04:50
spivlifeless: so sure04:51
lifelessspiv: thats a matter of raising that exception :)04:51
lifelessspiv: more than anything else, AFAICT.04:51
spivRight.  And there are tests about functionality too.04:51
spivSo if you *do* break it somehow, you'll know :)04:51
=== Adys_ is now known as Adys
lifelesswell, PQM will. But yes :)04:52
spivI think I'm still mildly in favour of having some sort of distinction between core code and plugins in cases like this so that we can better report errors (and attribute them to the right software), but not enough to cling to keeping this inconsistent with the rest of bzr.04:53
lifelessspiv: I think we can do that without any formal distinction04:54
lifelessstack introspection for instance, will be better done *without* rethrowing.04:54
igcpoolie: np04:55
spivDon't expect me to consider stack introspection to be cleaner than anything ;)04:55
lifelessspiv: I think we'd need that to get solid results always, anyway.04:56
poolieigc, i'm going to do the two small bugs i opened against bzr-website04:56
igcpoolie: I saw the gdesklets one. What's the other?04:56
pooliemention gnu04:56
igcpoolie: cool. could you also change Contribute/Plugins to ...04:57
igcthe new guide ...04:57
poolieis this in the wiki?04:59
igcpoolie: the current link points into the Wiki: http://bazaar-vcs.org/WritingPlugins05:02
igcpoolie: which just redirects to the new guide05:02
igcpoolie: I just want to cut out the extra click05:03
igcpoolie: the tutorial is part of the Plugins Guide now05:03
poolieyou're talking about the link in the web page footer?05:04
pooliei can do that05:04
poolieok, it's fixed in trunk but there's a permissions breakage causing it not to update on the live site05:23
=== abentley1 is now known as abentley
lifelessspiv: I think we need to use introspection because there are many ways a plugin could taint an action05:31
lifelessspiv: hooks are one special case, but not necessarily even the most common source of user experienced errors.05:31
lifelessspiv: https://code.edge.launchpad.net/~lifeless/bzr/hooks/+merge/1700505:32
lifelessmy yak for the day05:32
lifelessspiv: thanks05:35
spivNo worries.05:36
lifelessare automirror's internals ~= to my sketch ?05:39
lifelessspiv: because I bet its a post push hook, not a pre05:39
spivlifeless: oh, post tip change, yeah.  I didn't realise your code used pre.05:40
lifelessno worries ;)05:41
spmdamn I am tempted to mis quote you two out of context. all that smiles and no worries; all we need is a "she'll be right mate!"...05:42
spivspm: or a "no wuckas"?05:43
spmspiv: ok, I admit they're very low, but I do have *some* standards05:43
lifelessspm: Good on ya mate05:47
spm /ignore lifeless05:47
* spm wipes the tears of laughter from his eyes and tries to recall wtf he was doing....05:48
* poolie closes bugs05:49
poolieigc, do i recall correctly that some measurements last year found bzr doing better than git over a dumb http server05:54
igcpoolie: in bzr 1.x, yes05:55
igcpoolie: I think we may have gone backwards over dumb http in 2.x but I'm not sure05:55
poolieweb site is updating again now06:03
pooliespiv, hi, still around?06:29
spivpoolie: yep06:29
pooliein that bug 504102, the problem seems to be that the remotebzrdirformat in the registry is getting its network_name set06:30
ubottuLaunchpad bug 504102 in bzr "test_format_initialize_find_open has some isolation problems" [High,In progress] https://launchpad.net/bugs/50410206:30
pooliethis seems wrong06:30
pooliewould i be right in thinking it should only be set when you're talking about the format of some specific bzrdir?06:30
spivWhich registry?  The bzrlib.bzrdir.format_registry?06:31
pooliehm, apparently BzrDirFormat._known_formats06:32
spivBut yes, that's my understanding too.06:32
pooliei'm not sure how that meshes  with the format registry06:32
spivThe per_bzrdir load_tests explicitly adds remote bzrdirs to the list of scenarios.06:33
spivSo I'm not sure that the registry is involved.06:33
spivA remotebzrdirformat instance from that load_tests might still be inappropriately shared or mutated, though.06:33
poolieso it's not the registry, but rather the single instance of that format in the scenario list06:33
pooliei think all those tests will get a copy of the format06:34
pooliewe could give them a format_class instead06:34
spivPossibly the solution is simply to specify the default network_name at load_tests time?06:34
poolieif the format object can be mutated (implicitly by calling other things on it)06:35
lifelessYeah we assumed formats were immutable06:35
pooliethen it seems like asking for trouble for multiple tests to share an instance of it06:35
lifelessI think copying the Remote format in each scenario would make sense here.06:35
pooliealternatively we could make them actually immutable again06:35
pooliethat may be harder06:35
lifelesspoolie: Remote formats are proxies though, so its hard.06:36
spiv(let's go shopping)06:36
lifelesscouple of other random thoughts:06:36
lifeless - its possibly a bug, a test that should dup the format and writes to it: easy answer: fix that one test.06:36
pooliethey can only actually know this if they're connected to a particular instance of a bzdir06:36
lifeless - generally we get a RemoteFormat* via factory methods, so there isn't a reason for production code to be altering the scenario format object.06:37
poolielifeless: using the format to initialize a branch implicitly mutates it06:37
lifelesspoolie: oh MEEP06:37
lifelesspoolie: I consider that a bug06:37
lifelesssorry for introducing it06:37
poolieit looks ugly to me at least06:38
poolieeasier to reason about these things if they're immutable06:38
spivPerhaps initialising a branch should give that branch a copy of the remote bzrdir format?06:38
lifelessimmutable I think is hard here, but altering the parameter format should be unnecessary and can cause bugs.06:38
spivWhat lifeless just said :)06:39
lifelessMore generally immutable objects in python don't seem to work well: python is not geared for such idioms, with the notable exception of strings (and there too we run into performance and space issues)06:45
poolieso we may be able to just remove the sideeffect of setting the name when it's created06:47
poolieif nothing relies on that we should be ok06:47
lifelessWe'll want the format the branch uses to have the name set if we know it06:47
poolielifeless: this is the kind of thing i mean about the tension between the Format and the class of the instance06:47
lifelessprobably its passing in a format it should duplicate06:47
lifelesspoolie: well, RemoteFormat is a proxy object anyway; I don't see that this adds to that tension06:48
poolieit's kind of half a proxy object06:49
poolieobviously it can be a proxy for an actual remote bzrdir06:49
poolieit can also be exist in the abstract without one06:49
lifelesspoolie: I've recently in another project had cause to do format markers on disk again, and I used the split style we do in bzr again - I find it really easy and clear to work with - it made two separate hierarchies with separate concerns.06:49
poolieto me that is a reflection of the tension06:49
pooliewe have this bug06:50
lifelesspoolie: RemoteRepository can't exist in abstract; Remote*Format can - but then so can BzrDirMeta1Format06:50
lifelessit has state and can be parameterised.06:50
pooliei think the bugs we see here show that the code is not clear about what the object represents06:51
lifelessdoing that (BzrDirMeta1Format parameterisation) in the class would be really unpleasant, I think - it would make what shouldn't be global, global state)06:51
lifelesspoolie: Have a good weekend :)06:51
lifelesspoolie: [I'm still sick, can't really make a good case for or against anything atm, and this isn't a shallow discussion.]06:52
poolieyeah, thanks06:52
pooliedon't worry, i'm not going to pull it out now06:52
spivpoolie: which method is mutating the format do you know?  initialise_on_transport?06:53
lifelesspoolie: oh I know :) You'd have to replace all the things that work well at the moment with something cleaner, to pull it out :)06:53
spivpoolie: huh06:53
spivpoolie: that method already goes to the trouble to make a new RemoteBzrDirFormat object06:53
spivpoolie: so really it should be mutating that, not self, I think06:54
lifelesssometimes a bug is just a bug06:54
lifelessspiv: ack06:54
poolieline ~326306:54
pooliethat's what i changed06:54
lifelessspiv: ah, I see. I was stupid.06:55
spivlifeless: it happens :)06:55
lifelessspiv: it uses its own state to make the rpc call. It shouldn't.06:55
spivlifeless: right06:55
poolieit's used as both the archetype of the thing you want to create (in which case it can be partly populated)06:56
poolieand the actual value of a thing, in which case it should be fully populated06:56
pooliethere's not necessarily anything wrong with this...06:56
pooliebut, with object aliasing etc, it seems a bit dangerous06:56
lifelessshould fix i t06:56
poolieyes, thanks, i did that 20 minutes ago06:57
lifelesspoolie: cool06:57
pooliei'm waiting to see if it passes06:57
pooliebtw, what's the difference between known_formats and format_registry?06:58
lifelessoffhand: known_formats == svn, hg, bzr, git, cvs06:59
lifelessformat_registry == bzrmeta1 format logic06:59
lifelessnope thats wrong07:00
poolieit's something like that but i'm not sure if it really needs to be in a not-quite-a-registry07:01
lifelessI think known_formats is perhaps just what we had before format_registry07:01
pooliei think the format_registry is the registry of pre-baked combinations07:01
poolieas opposed to the list of BzrDirFormats07:01
lifelessthat bit I'm sure of07:01
lifelessthere is a commment explaining something about it07:02
lifelessit might be a thing to remove / turn into a separate object, but I'd need to page it in, look at what it has in it properly.07:02
pooliewas just wondering07:02
pooliei think this is passing so while it runs i will poke at tribunal07:02
pooliehave a good weekend07:02
lifelessAnother WAG - it will have BzrMetaDirFormat1, BzrDirFormat4, BzrDirFormat5 etc07:02
pooliei can see the different things that are registered07:03
pooliei guess i wondered if it really matters07:03
lifelesspoolie: the comment it has is about performance probing for stuff. No idea if thats still relevant.07:03
lifelessigc: I hope you don't land that --bind change - I really didn't see consensus on the list.07:12
lifelessoh, ugh. I just replied to a 5 year old mail.07:20
* lifeless blushes07:20
pooliehttps://code.edge.launchpad.net/~mbp/bzr/504102-test-isolation/+merge/17006 is the patch, still running i think07:21
lifelesspoolie: approved already :)07:22
lifelessjml: ping07:25
lifelessjml: I'd like to make your weekend hacking nicer; to that end care to approve my two testresources merges? ;)07:25
lifelessyou know what I'd love.07:25
lifelessimplicit per-product PPA's.07:26
pooliewould be great07:26
lifelesswith product relationships permitted to get product->product dependent PPA's.07:26
pooliei'd like a view of all bugs tagged hottest100 across all projects07:26
lifelesse.g. ppa:bzr/releases would depend on bzr-git/releases, if bzr-git was a relationship07:26
vilahi all07:26
pooliehi vila07:27
lifelessI think that would be awesome.07:27
pooliei was just thinking of you in bug 50464007:27
ubottuLaunchpad bug 504640 in bzr "selftest hang in test_bzrdir.TestHTTPRedirections_readonly.test_loop" [Low,Confirmed] https://launchpad.net/bugs/50464007:27
poolielifeless: if by 'depend' you mean 'virtually include' that would be even cooler perhaps07:27
* vila curses vbox for crashing again :-(07:28
vilapoolie: sounds a lot like the issues I encountered while debugging the leaking tests, say 90%07:29
pooliebut it's not really important07:29
vilapoolie: was it a full test run or a partial one ? --parallel involved or not ? (Not that it really matters, but it's always good to know a bit about the context)07:30
pooliefull, nonparallel, with -f07:31
lifelesspoolie: I do07:33
poolieshouldn't 'bazaar-ng' have been a clue? :-)07:40
lifelesspoolie: figured they had an old list ref07:43
eLowargreetings... what's the best way to safely backup a (live) Bazaar repository?07:46
=== jamesh_ is now known as jamesh
PengeLowar: Using Bazaar itself would probably be best, except for the possibility of corruption.07:54
spiveLowar: http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/backup.html07:55
spivPeng: I know, actual documentation addressing things users care about, weird huh? ;)07:56
PengTrying to take all the fun out of figuring out solutions, huh?07:58
spivPeng: not sure, give me a sec to find the docs on that topic ;)08:03
eLowarthanks a bunch08:19
Pengspiv: Maybe there's a blueprint!08:21
eLowar_oh and sorry for running off like this ;) I'm at work and we were trying to find this documentation, so I can't stay and chat right now :)08:22
spiveLowar: that's ok, glad we could help :)08:22
* igc dinner08:32
vilapoolie: so, about leaking tests, another way to look at it is to realize that the hang you encountered is one aspect of it. The irony is that the more bugs I fix in this area, the more likely it becomes to trigger hangs. That means all the related bugs should be fixed or we shouldn't touch it at all (and hope we keep being lucky to avoid it on pqm) :-/08:32
vilapoolie: I was close to fixing them all (famous last words) when I realized that while running full test runs without --parallel (which change the context enough to change the overall behaviour in various ways ...)08:34
lifelessvila: that while [...] what ?08:43
vilathat, while08:44
lifelessvila: I still can't parse it08:52
lifelessvila: In english, the that that you have before the while implies a clause to which the that will bind08:52
vilaWhen I stopped working on that, I had the full test passing with --parallel=fork (and 8 threads)08:54
vilaFrom there I wanted to run witout --parallel=fork to get data on how tests were still leaking (the report doesn't work with --parallel)08:54
vilaThe runs hang08:54
vilathat (while ...)08:55
lifelessso what report? we could do it in --parallel probably08:55
vilayeah, that seems to be our best protection so far08:56
jszakmeisterHello all09:13
bialixhello all09:36
vilalifeless: ghaa, I totally misread you remark, so the report that failed is the one about the leaking tests which presumably is lost into the test reporting (search for leak in tests/__init__.py, that's the first occurrence)09:51
ChrisMorgan"Treeless" when creating a branch means that you don't get the working copy, doesn't it?09:55
bialixhi vila09:58
vilahey bialix09:58
lifelessvila: can I suggest a refactoring09:59
lifelessvila: change the leak implementation to use tags09:59
lifelessso the result object accumulates tagged tests as leaking09:59
lifelessand the leak detection sets tags. Assuming that that is possible.09:59
lifelessthat would flow through subunit fine.10:00
vilalifeless: ok, pasted in my associated BRANCH.TODO, I'll look into it when I get there10:01
ChrisMorganAlso, I've got my own project which has two main chunks; a Python library (which goes in site-packages or somewhere in PYTHONPATH) and the actual Django projects (a sample one and then one for each client I get so I can keep 'em all).  How am I best to initialise my bzr repository?10:06
ChrisMorgansubtrees somewhere or something like that?10:06
ChrisMorganI've got half the buzzwords but haven't figured them all out entirely yet10:06
bob2a branch for each10:06
ChrisMorganEven though it's all the one project really?10:07
bob2sounds like they're not one the project10:07
ChrisMorganI thought maybe the client ones should each be in a branch of their own but I thought I might do the library and sample one in the same or something10:07
lifelessChrisMorgan: sounds to me like the python library is one project; and each django thing is another separate project.10:09
ChrisMorganI'd be able to branch of one repository and then push to a different one... that'd work well with separate branches10:09
lifelessChrisMorgan: s/repository/branch/ there.10:09
lifelessChrisMorgan: repository != branch10:09
ChrisMorganOh no... I'm confusing my talk :S10:10
ChrisMorgan*sigh* :-)10:10
ChrisMorganI know what I meant at least, and so did you :-)10:10
ChrisMorganCould I use a shared /repository/ for these branches though?10:10
lifelessof course10:11
lifelessthere aren't any limits on sharing10:11
ChrisMorganDo I need to do anything special with my bzr init?10:11
ChrisMorganDo you think I should use development or 2a?10:12
lifelessuse the default your bzr has10:12
lifelessunless you have specific reason not to10:12
ChrisMorganNow how do I create separate branches in the repository?10:13
ChrisMorganI've never gone through and created a project in Bazaar... only used the Inkscape one before this.10:13
ChrisMorganAnd they're using knit :/10:13
lifelessChrisMorgan: bzr init path10:13
jszakmeisterIs there a way to dump the contents of a pack file (in a semi-readable fashion)?10:14
lifelessjszakmeister: with python, yes10:14
lifelessbzrlib.pack has the API10:14
ChrisMorganlifeless: so, bzr init-repo myproject, bzr init myproject/lib, bzr init myproject/sampleclient, bzr init myproject/[companyname], etc.?10:18
ChrisMorganCould I do bzr init myproject/clients/sample etc. if I just create the clients directory?10:18
ChrisMorganOr would I need to init clients first...10:18
jszakmeisterOkay... next question: is there an easy to see some sort of formatted output of each record in the pack? :-)10:19
jszakmeisterI'm trying to understand this ghost revision stuff a little more and I'm not quite understanding how this error is being generated:10:21
jszakmeisterbzr: ERROR: Revision {StaticTuple('1@7e532cae-f599-4488-b39e-a91bcf8c4cdd:%2Ffile.txt', 'john@szakmeister.net-20100108092733-qdawmc2foo77br14')} not present in "<bzrlib.groupcompress.GroupCompressVersionedFiles object at 0x15cb4f0>".10:21
jszakmeisterIf I cat the revisions, none of them point to john@szakmeister.net-20100108092733-qdawmc2foo77br1410:21
jszakmeisterBut that information is obviously recorded somewhere. :-)10:22
* ChrisMorgan wonders whether Bazaar or some other version control system could be twisted to version the contents of a database rather than the filesystem10:22
ChrisMorganjszakmeister: I presume no matches for just qdawmc2foo77br14 either?10:23
lifelessChrisMorgan: mkdir myproject/clients and otherwise, yes.10:23
ChrisMorganOK, thanks lifeless :-)10:24
ChrisMorganThank you, you and bob2 have been very helpful :-)10:24
lifelessjszakmeister: it will be in an inventory10:25
lifelessjszakmeister: in the parents graph, I expect10:25
jszakmeisterWhere can I find that?10:26
jszakmeisterOkay, I'll give that a whirl.10:27
jszakmeisterBefore I do, lemme ask another question...10:27
jszakmeistercurrently, bzr-svn is setting the parent on one of the files to point to that revision...10:28
jszakmeisterin a merge commit... should it be doing that?10:28
jszakmeisterbzr check seems to dislike it:10:29
jszakmeister     1 inconsistent parents10:29
jszakmeister      * 1@7e532cae-f599-4488-b39e-a91bcf8c4cdd:%2Ffile.txt version john@szakmeister.net-20100108092741-ei1r6ocf3zfl6e6u has parents ('john@szakmeister.net-20100108092733-qdawmc2foo77br14',) but should have ()10:29
lifelessits a revision that you are missing; you should pull it into your repo and it will stop being a ghost10:30
jszakmeisterWell, it's not that easy.10:30
jszakmeisterIf someone branches svn trunk, does all their work in bzr, and then merges it back to svn trunk... you end up with this problem.10:31
jszakmeisterIOW, it's quite easy to end up in this state.10:32
ChrisMorganIf I want to just straight rename a branch in my shared repository - my product has a current code name but I'm not decided on its final name yet and might like to rename it - what's the command for that? I presume there is some way I can do that short of something like branch company/product, push company/newname.10:33
bob2real mv not bzr mv10:33
PengOf course, you're still stuck with any branch nicks stored in history.10:34
ChrisMorganAnd that continues to work even though the branch information is stuck in the repository rather than the branch?  (Or is it?)10:34
bob2the revision data is in the repository10:35
bob2the branch data is in the branch10:35
PengChrisMorgan: What are you asking?10:35
ChrisMorganPeng: repository with branch a/b, want to rename the branch to q/b10:36
ChrisMorganOK bob2, I thought with a shared repository the branch info was all stored in the repo rather than the branch?10:36
PengChrisMorgan: What do you mean by "branch info"?10:36
PengChrisMorgan: I think you're misunderstanding something.10:37
ChrisMorganall the history etc. of files10:37
ChrisMorganAm I?  :-(10:37
ChrisMorganPlease correct me :-)10:37
PengChrisMorgan: Yeah, revisions are stored in the repo.10:37
ChrisMorganSo if I rename the branch ---10:37
ChrisMorganWhat happens?10:37
PengChrisMorgan: Bazaar doesn't care about what the name of the directory is. (Except for the default branch nick.) As long as you don't move it outside the shared repository, you can call it whatever you want to.10:38
ChrisMorganCould you for example in Launchpad just 'mv inkscape.dev inkscape.devel' and have it continue on chugging with everything moved across to lp:inkscape/inkscape.devel?10:38
ChrisMorganDefault branch?10:38
ChrisMorganDon't think I've heard any mention of that...10:38
PengChrisMorgan: On-disk, all a branch is is a pointer to the most recent revision ID and some meta data (like the parent location and tags).10:38
PengChrisMorgan: default (branch nick)10:39
PengChrisMorgan: Not (default branch) nick10:39
ChrisMorganOh dear... I'm more confused now :-)10:39
ChrisMorganNever mind, I'll search for it10:39
ChrisMorganI'm off to bed now anyway.10:40
PengSorry. :<10:40
ChrisMorganI'll continue on asking tomorrow then for anything I still don't understand :-)10:40
PengChrisMorgan: I just meant the name of the branch that's recorded in history.10:40
PengChrisMorgan: Which is just a little bit of meta data that doesn't actually matter.10:40
ChrisMorganPeng: OK10:40
ChrisMorganI'll blindly name branches and hope I can rename them later :-)10:40
ChrisMorganBye now.10:40
PengChrisMorgan: You can, but you can't change the nicks stored in history.10:40
PengChrisMorgan: See you. :)10:41
ChrisMorganWhere's it stored though?10:41
PengChrisMorgan: As part of each revision.10:41
PengChrisMorgan: Look at "bzr log".10:41
ChrisMorganOK, thanks10:41
ChrisMorganBye now for real ;-)10:41
jszakmeisterlifeless: and it's even more problematic when there is another person on a different team who doesn't have access to our bzr mirror (firewalls, policy, etc)10:46
=== mrevell is now known as mrevell-lunch
=== mrevell-lunch is now known as mrevell
marek_hi, can i upload only specified trunk? i already dowloaded upload plugin14:32
rubbsmarek_: what do you mean? you only want to upload a specific directory?14:36
lornajaneI want to start using bzr-svn, but I have two problems.  Firstly, I haven't used bzr much.  Secondly, its an ubuntu 8.04 server.  Can anyone help me begin?14:47
lornajanethe packaged bzr-svn is 0.4.9-1, which I think is quite out of date14:49
maxblornajane: You'll definitely want to add the ~bzr ppa, where you can get the latest released version of bzr and some associated plugins14:54
rubbslornajane: you could try to use the ppa that the bzr team maintains. https://launchpad.net/~bzr/+archive/ppa14:54
rubbsbzr-svn is in it14:55
rubbsmaxb: you beat me ;)14:55
lornajaneah, thanks people14:56
=== nailuj24 is now known as nailuj
=== nailuj is now known as nailuj24
rubbsalso if you are new to bzr you could also check out the tutorials.14:57
rubbswe have a new admin doc too... if it's not in the official it's in the beta release of documentation. It should still work for the current versions too14:58
rubbsI'll see if I can dig up a link for you14:58
lornajanethe tutorials looked good, one reason I thought I could give it a try14:59
rubbssorry for the long delay got a phone call15:18
lornajaneno worries at all, I appreciate your input!15:19
rubbsoh, that link is to the "beta" documention, but just about everything (if not everything) will work with the currently supported version. The documentation was added after that lastest release, and they probably won't backport it.15:22
lornajaneno worries, if something doesn't work I can dig or ask for help.  I'm only doing really really basic stuff, making changes and comitting them to svn, but want some of the offline features as I am on the road alot15:23
rubbsyou'll probably like bzr and bzr-svn then.15:25
lornajaneI hope so.  I know a lot of people using git, but I think bzr will suit me better15:26
rubbsI'm just starting to learn git (work is finally getting a VCS) and I can say that for many things I like bzr better. but Git is a good one too.15:27
lornajaneI'm a very confident SVN user, but I will probably only use a few features of either git or bzr ... I'm more confident on getting help with bzr which is what swung it15:28
rubbsgood to hear. I and others are glad to hear that. we are trying hard to make it easy to get into bzr.15:31
lornajanethe docs are brilliant, the users I've met are friendly - I can't ask for more than that :)15:32
LeoNerdHow do I show a diff of a shelved change without actually unshelving it?15:37
LeoNerdbzr unshelve --dry-run  only prints the summary, the filenames...15:37
=== beuno is now known as beuno-lunch
maxbLeoNerd: I think first you implement the code to do that :-/16:02
LeoNerdAhhh... hrm16:04
KinnisonLeoNerd: then you contribute it upstream because that'd be handy for me16:04
LeoNerdHeh.. as if my TODO list wasn't big enough already :P16:06
LeoNerdWell, actually it's more of a TODO tree.. and it's both deep and wide.. I'm on a 4th level dependency16:06
fullermdIt's hard sometimes to see the TODO forest for the TODO trees.16:07
=== beuno-lunch is now known as beuno
dobeyi just want to say how happy i am that bzr is designed the way it is16:48
=== deryck is now known as deryck[lunch]
ezodhello, quick question17:36
ezodif i have a branch, bound to a remote branch, and i do a commit --local17:37
ezodis there a better way to subsequently push that commit to the (bound) remote branch than bzr push <url>?17:37
ezodi.e. without respecifying the url that it is already bound to in branch.conf?17:37
ezodcoming from git, i would have thought bzr push with no argument would do the trick17:37
beunoezod, once you push, it will remember the location from then on17:38
ezodyes, it does (url lives in branch.conf), but just "bzr push" still says "bzr: ERROR: No push location known or specified."17:39
ezodi see what you mean17:39
ezodthe "saved push location"17:39
beunoI agree that not having a good default sucks a bit17:40
ezodwould it not make sense for that to be populated with the current bound location?17:40
beunowell, yes17:40
beunoI think so17:40
beunobut other devs tend to disagree (for good reasons as well)17:40
ezodat least, if it's not already been populated otherwise17:40
beunobring it up on the mailing list, we can take another stab at the subjectx!17:40
ezodwilco, thanks :)17:40
ezodeven like, bzr push --bound or something would be nice17:41
ezodas my current workflow involves digging in branch.conf for the url17:42
beunoI think you can do something with revisionspec17:42
* beuno looks it up17:42
fullermdbzr push :bound17:45
beunothat's it17:45
=== abentley1 is now known as abentley
ezodoh, well that's excellent17:46
fullermdThere are aliases for all the saved locations.  :bound, :push, :parent, etc.17:48
ezodvery convenient17:48
ezodso :X for X_location in branch.conf i suppose17:49
vilaezod: I generally use bzr bind :push, but that's just to contradict fullermd  ;-D17:55
orattueis it possible to update a checkout to a specific revision number? e.g. checkout is on revno 10, latest revision of trunk is 20. Can I update my checkout to say revno 15?18:26
beunoorattue, I think update doesn't take a revision18:27
orattueso I would have to branch18:27
beunoon a branch, sure18:27
beunobzr pull -r REVNO18:27
=== deryck[lunch] is now known as deryck
fullermdIt will in 2.1.  But prior to that, yeah, you're down to creating a new branch to fling around with pull.18:38
maxbHi. Does anyone know why bzr reconfigure has --with-trees and --with-no-trees instead of just --trees and --no-trees?19:00
maxbIs it because the option parser would construe the latter as a single boolean, and reconfigure needs tri-state logic?19:01
jammaxb: My guess is that whoever wrote the option wanted "--with-trees" to indicate an action19:01
jamas "--trees" doesn't really say that you are adding anything19:01
* maxb was wondering about adding options to control append_revisions_only19:02
Lostinspace_46I am running Karmic.  I have tried every permutation of this command...[cp src/bzr-2.0.0-0ubuntu1 public_html/my-repository/binary/] that is bzr2.0.0 and bzr_2.0.0.  I keep getting this msg...cp: cannot stat `src/bzr-2.0.0-0ubuntu1'.  I am brand new to this, and have no idea what is wrong. Can someone help?19:03
jamLostinspace_46: let's start by finding out what you are trying to do with this copy19:04
jamare you trying to publish a deb file?19:04
jamare you trying to install a ppa?19:05
Lostinspace_46jam not quite, I am trying to create a repository as per http://mediakey.dk/~cc/howto-create-your-own-debian-or-ubuntu-package-repository/19:05
jamLostinspace_46: I think you are starting pretty far down the road19:06
jamthat guide assumes you've already created 'deb' files19:06
jamand are just publishing them19:06
jamas a debian repo19:06
jamYou need to go look for a guide as to how to create a deb package first19:06
Lostinspace_46jam well in a way I am.  I am tired of fighting dependencies, so I decided it would be easier to repack "from site" as debs and put them in a repository so I can use deb installer.19:08
Lostinspace_46"from site" pkgs that is19:09
jamLostinspace_46: Do you have a bzr deb that you are trying to set up this way?19:11
jamAt a minimum, I would expect it to end in ".deb"19:11
jam(this also is a bit off-topic for #bzr, but we can try to help)19:11
Lostinspace_46jam Why is it off topic? That's not an arguement, I just don't understand. And if you know a better place to ask, I will.19:13
jam#bzr is a place to ask questions about the Bazaar Version Control System19:13
jamnot really debian packaging and repositories19:13
jam(or ubuntu using debs, etc)19:13
jam#ubuntu might be better19:13
Lostinspace_46jam Hmm, I think I follow. I'll try #ubuntu.  Thanks for the help.19:15
rubbsmy job just decided to finally get a VCS (I've been fighting for this since I got here) and they chose git. (decision made without me really) I'm very used to bzr. how feasible is it to do development with bzr-git? is there a git tutorial for bzr users? I've tried asking on #git, but no-one's answering. I"m not expecting anyone to know this stuff off the top of their heads, but I thought I'd ask.19:35
ronnybzr-git mostly works, it cant yet do normal push tho, as git lacks metadata support, so you'll have to use dpush+rebasing19:45
rubbsis there any tutorial on how that works? coming from bzr I've never rebased (or needed to).19:46
jamrubbs: I believe jelmer uses bzr-git to develop dulwich (the python git bindings)19:46
jamrubbs: it amounts to using "dpush $UPSTREAM" rather than "push"19:46
rubbsjam: ok, cool thanks.19:46
jamwhich, IIRC, will rewrite your local branch to be based on the new git commits19:47
jamIt does mean there is some headaches if you do a lot of merging on the bzr side19:47
rubbsmmm... well maybe I'll try some trial stuff on a test repo or two to see if I can get my work flow to work. If not I'll just learn git. It couldn't hurt to know them both.19:48
mtaylorhey ho...21:06
mtaylorbzr: ERROR: CHKInventoryRepository('http://bazaar.launchpad.net/~drizzle-developers/drizzle/development/.bzr/repository/')21:06
mtayloris not compatible with21:06
mtaylorelambert:drizzle elambert$ bzr upgrade --2a lp:~elambert/drizzle/gearman_replication_applier21:07
mtaylorbzr: ERROR: The branch format Meta directory format 1 is already at the most recent format.21:07
bjesusanyone knows how the see the current revision in my working tree?21:24
bob2bzr revno21:24
bob2or do you want the revid?21:24
bjesusnope, i've got a lightweight checkout which isn't always updated. revno gives me the latest revision on the master branch21:24
bjesuswhat's the revid?21:24
bob2a globally unique identifier21:25
bob2revnos are only useful within a particular branch21:25
bjesuswell no, i guess that i want the revno, but i want to know the latest current revno, not the latest available. when running bzr revno from my lightweight checkout it connects to the server and tells gives me the latest revision21:26
fullermdrevno --tree21:26
bjesussays there's not such option... is it new or something?21:27
fullermdNot terribly.  1.17, NEWS says.21:28
bjesusum... centos latest is 1.7.1... i'll try to update, thanks.21:28
bjesusthanks fullermd. i compiled 2.0.3 from source and it worked. but, now i still asks me for password, even though it shouldn't connect to the remote server at all. why is that? is there a way to skip it?21:40
m3gahaving some trouble writing a bzr pre-commit hook plugin. can someone please have a look at this : http://paste.lisp.org/display/9315921:45
m3gaand explain whats wrong?21:45
m3gai have written any python since 2003. most use C, C++, ocaml and haskell21:46
fullermdbjesus: Well, it has to have a branch context to give you a revno.21:51
bjesusfullermd: why? I mean, last time i did 'bzr update' it wrote the revision it updated to, so why can't i see it again?21:52
bjesusfullermd: anyway, i need to see that revision without a password. would writing a hook be good?21:53
fullermdBecause a revno only has meaning in the context of a particular branch (technically, a particular head), because it's related to the position in the branch.21:53
maxbbjesus: It wrote the revision id ( a string like launchpad@pqm.canonical.com-20081022214747-h2sphj9zcuh1c1cq ) but to look that up to get the number, it needs to talk to the branch21:53
fullermdYou could get the revid without connecting probably, with revision-info21:53
fullermdAnd the revno may be different now than it was when you update'd.21:54
lifelessm3ga: findall doesn't take a regex, it takes a string for the regex21:54
lifelessm3ga: if you have a regex, you call regex.match, or whatever.21:54
m3gare.search gives the same error21:55
bjesusfullermd: nope, revision-info also askes for the password. can i write a hook that creates a text file with the revno each time i do 'bzr update'?21:55
lifelessyou are doing21:55
bjesusjust checked, seems like there's only post_pull but no post_update... :(21:56
lifelessre [the module].findall [the convenience function] (copyright_re [the regex object], ...)21:56
fullermdOh, it shows the revno too.  Mmm.21:56
lifelessm3ga: thats wrong - use the object directly!21:56
lifelessm3ga: or21:56
lifelessm3ga: do re.findall(thestringyouwantcompiletoaregex,...)21:57
fullermdI've got an alias for revid that uses 'version-info', but I'm not sure whether that checks tree or branch.21:57
fullermd(and probably isn't smart enough to pre-optimize what info it looks up anyway)21:57
fullermdbjesus: The problem is, that revno from then may not be of any use to you.21:57
m3gacopyright_re.findall (content) -> bzr: ERROR: exceptions.TypeError: expected string or buffer21:58
lifelessm3ga: ok, so what is content21:58
m3gacontent = future_tree.get_file_lines (file_id)21:58
lifelessthat will be a list of lines21:58
lifelesscontent = ''.join(future_tree.get_file_lines (file_id))21:58
lifelessactually,there is a helper in osutils somewhere, but the above will get you going21:59
bjesusfullermd: revno is of use for me. why do you think it isn't? you are right though, version-info does gives me the current revno. but, it also asks for my password...21:59
m3gayay! compile time types would have been nice :-)21:59
m3gathanks lifeless21:59
fullermdbjesus: Because the revno of that revision in that branch at the time you updated may not be its revno now.22:04
bjesuswhy not? how can it be changed?22:05
fullermdIt can potentially change any time the head of the branch moves.22:05
lifelessm3ga: np22:06
fullermdIt may happen all the time, or it may hardly ever happen, depending on the workflows you're using.22:06
lifelessunless you set append_only22:07
lifelesswhich you can if you want revnos to be stable22:07
fullermdIt may be that caching it would "usually" tell you something useful, in your setup, but there's no way to be sure other than checking.22:07
fullermdWell, that would be one permutation of 'workflow'   :p22:07
bjesusi don't get it. I've got A and B doing bzr commit and bzr update to C. both A and B a are lightweight checkouts, and C is just a server, no work being done there. When doing bzr commit', bzr tells me "commited revision xxxx". and it never changes...22:07
m3galifeless: quite honestly, coming back to python after not using it for over 5 years is just as confusing as using haskell for the first time22:07
lifelessm3ga: If you want to write bzr-haskell [bindings], that would be fine with me :)22:08
bjesuswhat's append_only?22:08
fullermdIf two lightweight checkouts are the only way revs ever get into it, it would probably be pretty difficult for the numbers to change.22:08
fullermdbjesus: http://wiki.bazaar.canonical.com/MatthewFuller/AboutMainline is a moderate-length discussion of the numbering.22:08
m3galifeless: NO!22:08
lifelessbjesus: its a setting which prevents revnos that are allocated ever changing [in a given branch]22:08
lifelessbjesus: for instance, if you want to see a revno change in your setup, the 'uncommit' comand will do that:22:09
lifelessit will pop the most recent commit off your branch, and then when you commit again you'll 'reuse' the revno.22:09
bjesusand do think that if i'd set append_only on, it wouldn't ask me for the password?22:09
lifelessfullermd: ^ simplest explanation I know of: its clear, selfcontained, doesn't need discussion of merges mainlines etc22:10
* fullermd files that away for reuse.22:10
lifelessbjesus: its asking for the password because you're doing operations over the network.22:10
fullermdNo, that setting just makes it take extraordinary effort to cause the revnos to change.  It doesn't change bzr needing the branch context to figure them out.22:11
bjesusokay... and if i'll do with the revid, which as i far as i can understand is unique and never changes - would then there would be an option to see the current revid without networking?22:11
fullermdNot through the UI, I don't think.  You could get it by manually poking under the covers.22:11
lifelessbjesus: if you're using lightweight checkouts, every operation that inspects the tree will connect to the network.22:12
lifelessbjesus: with no exceptions.22:12
fullermdEither with a little bzrlib usage in python, or by writing a stupid parser that knows just enough of the dirstate format to yank it out in your Language Of Choice.22:12
lifelessfullermd: bzrlib won't permit it either, not while using any of the support abstractions22:13
fullermdOh?  You can't just open the tree without it looking for the branch?22:13
lifelessfullermd: correct22:13
fullermdThat sounds bogus.22:13
bjesusso there's no way to know when the checkout was last updated without network if using lightweight checkouts?22:14
lifelessfullermd: it wants a branch object, that could be a thunk.22:14
lifelessbjesus: thats correct22:14
bjesusyeah, tried bzr lib before. it asked me for the password too...22:14
lifelessbjesus: in fact, there's no way to know at all, because we don't store 'when an update was done', only 'revision parents' - which is a totally different thing.22:14
lifelessso you can figure out what the parents are, and they can be used to get a lower bound on the time of the last commit22:15
fullermdWell, you could guess "when" from timestamps.  But you presumably don't really want to know "when", you want some pointer to "what revision".22:15
lifelessor at least on the time on the machine that did the last commit which has been pulled into the tree22:15
bjesuswell yeah but i don't care much. be it either when or what revision, i just need to know something about what files i have on my lightweight checkout, whichout connecting... 22:16
fullermdOf course, you couldn't even figure the dates of the commits without talking across the network on a light co.22:16
lifelessbjesus: I missed your initial problem statement. What are you trying to achieve?22:17
m3gais there a neater way of failing out of a pre-commit hook than raising a ValueError?22:20
bjesussimple. i've got a web application in a bzr branch on server A. it isn't being used there, it isn't even running. just the code is there. Server B and C are running the application, and sometimes i change something in the code in one of them. I can do a lot of commits on server C, and before upgrading server B, i want to know it's state. So i want my web application to be able to tell the current revision, so i can just go to myapp.com/revision and it would y22:20
bjesusthe revision it's running. but i can't find any way to get that revision without entering the password, and i don't want to use ssh keys here.22:20
lifelessm3ga: raising an exception is correct22:21
lifelessm3ga: ValueError is ok, BzrError with a format string might print nicer on the console22:21
lifelessbjesus: it cut off at 'would y22:22
bjesuswould yank the revision it's running. but i can't find any way to get that revision without entering the password, and i don't want to use ssh keys here22:22
m3gawhere do i import BzrError from?22:23
fullermdSo, you could cache the revid (or suck it out of dirstate) somehow, and it would always be right.  You could cache the revno somehow, and it would maybe be right.22:23
fullermdIt sounds like you're running out of the branch directly, rather than having the files installed by some sort of build process you kick off, so you couldn't jam something in there.22:23
fullermdIf keyword support was more mature, you could use that.22:23
bjesusyeah, i'm running out of branch directly since it's an application which is constantly changing. from what i've checked, seems like keyword support isn't there it and mostly works with bzr export. what do you mean "cache the revid"? how? got any pointers?22:26
fullermdNot really.  If I had to ugly-do it today, I'd bung up a few lines of code to scrape it out of dirstate.22:27
bjesusumm... seems like getting the revid from dirstate isn't hard - it's quite a the top. i can't find revid there but maybe i'll go this way..22:29
bjesus*can't find revno there22:29
fullermdIt isn't.22:29
fullermd(AFAIK, and I'd be surprised)22:29
bjesusyup, it isn't. thanks a lot anyway, i'll see what i can do from here :)22:30
lifelessm3ga: bzrlib.errors22:42
lifelessbjesus: I can suggest two things for you22:43
bjesusi'd be glad to hear22:43
lifelessbjesus: one, a post pull/update hook to stash the info for you22:43
lifelessbjesus: e.g. it would invoke bzr version-info for you22:43
lifelessbjesus: alternatively, when you update do that manually22:44
bjesuswell, i can do it manually but i've got some other users which would create a mess. as for the hook - that sound's good, but by looking at the hooks list it seems like there's a post_pull but not a post_update hook.22:46
bjesusactually, what would happen if i'll start doing 'bzr pull' instead of 'bzr update'? is there a difference? can a lightweight checkout do that?22:47
lifelessbjesus: you need a branch to be using pul22:51
lifelessbjesus: we can add a hook for post_update quite easily. Its, oh, 15 lines of code-and-docs or so, plus a test or two.22:52
bjesuswell, isn't my main server a branch? i'm doing bzr update from there, isn't it a branch?22:52
lifelessbjesus: the object you are updating is not a separate branch22:52
lifelessbjesus: if you pull, you'd be altering the main server as well because thats where your branch is22:53
bjesusoh, got it.22:53
bjesusso you say i should fill a RFE for post_update?22:55
bjesusokay, last question - what's WorkingTree.post_parents_change ? :p22:58
lifelessthe name of the hook you should ask for22:59
bjesuswhy not post_update?22:59
lifelessI prefer to make the most useful hook I can when adding a new hook23:00
bjesusbut what does post_parents_change means? how is it different?23:00
lifelesscommit, push, pull, uncommit will trigger it as well23:01
maxband merge?23:01
bjesusoh, okay23:01
lifelessup-thread, down-thread, pump too23:01
lifelessbjesus: oh, just file a bug23:19
lifelessbjesus: blueprints are generally massive overkill23:20
bjesusyou sure? it's not really a bug, isn't it? i mean, it's not like there's something wrong about bazaar... :s23:20
lifelessbjesus: I'm sure23:22
lifelessbjesus: bugs are not exclusively 'a defect in what we thought was working correctly'23:23
lifelessbjesus: more generally, we don't manage work via blueprints: most of our work is bug centric, so blueprints tend to get ignored, and launchpad doesn't provide an integrated view.23:24
lifelessI wish blueprints and bugs were merged in launchpad in fact; it would be a lot simpler to work with.23:24
lifelessif they were,for example, a slightly different UI on the same underlying concept23:25
bjesusokay, i'm filling a bug report.23:25
NfNitLoopHrmm.  I thought I read that bzr-svn would populate svn:merge properties.  Does it not read them as well?  this branch's history looks very linear when it's mostly merges from another.23:25
lifelessNfNitLoop: I don't know if it reads them yet, jelmer would know but hes on a plane23:26
NfNitLoophow inconvenient for *me*!  ;)23:26
NfNitLoopI s'pose I could read some docs.23:26
* NfNitLoop does.23:26
* fullermd . o ( irssi connect --bind... )23:27
NfNitLoopaah:  Other features currently held back by Bazaars feature set:  Showing SVN merges as merges in Bazaar23:28
bjesus@ https://bugs.launchpad.net/bzr/+bug/50499723:29
NfNitLoopthat's OK then. :)23:29
ubottuLaunchpad bug 504997 in bzr "post_parents_change hook" [Undecided,New]23:29
bjesusoops :) didn't know it would happend automagically23:29
lifelessbjesus: it doesn't, you referenced it23:31
maxbNfNitLoop: What do you mean by svn:merge? That's not a normal property23:33
maxbYou probably mean one of svnmerge-integrated, svk:merge, or svn:mergeinfo23:33
NfNitLoopah, svn:mergeinfo. Whatever it's called. ;)23:34
maxbYeah. I kinda need support for that too :-)23:35
NfNitLoopI can see why it's not there.  in svn you can merge in any revision (cherrypick).  You can't quite do that in bzr.23:36
fullermdWell, you can also merge in random files or subparts of a branch (or superparts of a branch, come to that)23:37
NfNitLoopoh, good point.23:37
NfNitLoopyeah, SVN's data model is...  special. :p23:37
ronnyit woultn be that much of an issue is svn had propper tools to work with that, but it doesnt23:39
fullermdMmm.  "superparts" is an interesting etymological construction...  I'll have to try using it sometime it can really mess people up.23:39
NfNitLoopronny: what would propertools to work with that look like?23:39
ronnyNfNitLoop: something that helps figuring the relations between subtrees23:40
NfNitLoopaah. yeah.23:40
fullermdSeems tough to do, since the relation among subtrees is entirely transitory.23:41
NfNitLoopwell, you can sortof do that.  Just "svn log" till you see the branch copy, then you know those two things are branches of each other.23:41
ronnyfullermd: thats why svn's history model is a complete engineering fail23:41
NfNitLoopor, at least, were at one time.23:41
ronnyif one needs seriously smart tools to figure what the history is like, something is wrong23:42
ronnyhg/git/bzr do better there23:42
fullermdWell, by restricting the meaningful actions.  That's an easy way to make existing models capable of holding your results   8-}23:46
ronnywell, filtering out all the stuff that is insanely hard to support23:48
NfNitLoopand/or nonsensical.23:48
fullermdEye of the beholder.23:49
ronnythe kiss principle is powerfull23:49
fullermdSVN lets you "branch" a file within a branch, and merge changes.  It's not overly hard to dream up cases where that's useful.23:49
fullermdBranch subparts of a branch has its uses too.23:50
ronnyfullermd: working with strict subtrees can actually be simple23:50
ronnybut svn doesnt restrict it23:51
fullermdWell, there are a lot of bits&pieces of these things that aren't conceptually hard to do in a DVCS, except for the 'D' part.23:51
ronnyD part ?23:51
fullermdI mean, if your repository is all in one place, who cares that you have to [internally] copy 200 gigs of history to copy the 180k of history for the subtree you're branching?23:51
fullermdWhereas if you're distributed, you care a whole lot.23:52
ronnyfullermd: thats where partial history support starts to matter23:52
ronnybzr has, hg will have, no idea about git23:52
fullermdWell, but there's two types of partial history support involved.23:53
lifelessgit has alternates, functionally equivalent to stacking23:53
fullermdOne is simple horizons, which any of the above can do.23:53
lifelesshg has punching, which is a bit different23:53
fullermdThe other is slicing subsets of the tree, which is a LOT harder.23:53
ronnylifeless: punching?23:53
fullermdhg might have the easiest time; I think their lower levels are a lot more file-oriented than bzr/git.23:53
lifelessronny: history punching, its what hg calls it23:54
fullermd(certainly their storage is, but I have vague memories of discussions suggesting that it leaks up higher too)23:54
lifelessthey keep the index, but discard the content23:54
ronnylifeless: thats not what i meant23:54
ronnylifeless: there was some work on something comparable to bzr ghost revisions23:55
ronnylifeless: i dont think punching is in the actual official hg, seems more like a external patch23:57

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!