* Verterok waves greetings00:00
Verterokjfroy: it looks like a bug un setuptools :(00:00
Verterokjfroy: or an old version00:01
jfroyVerterok: not part of setuptools, that's part of bdist_mpkg00:02
Peng_How do you get "bzr: ERROR: No module named tests" when running from source?! :(00:02
Peng_Ahh! Plugin! Heh00:02
Verterokjfroy: right, it seems to be fixed in trunk00:02
Peng_That's what I get for not reading hte traceback first.00:03
jfroyVerterok: Ah, I see00:03
Verterokjfroy: the trac instance seems to be down, but you can get it from the svn: "< impl> I didn't realize Aerdan had prioritized the animals he wants to have sex  with"]00:04
Verterok19:48 < mxpxpod> jelmer: ok, thanks00:04
Verterokworng paste :p00:04
Verterokjfroy: http://svn.pythonmac.org/bdist_mpkg/bdist_mpkg/trunk/00:04
jfroyyeah I got it :)00:04
jfroyVerterok: seems to work great00:05
jampoolie: can you call back?00:07
lifelesshi poolie00:09
jfroyVerterok: yup, works :)00:09
Verterokjfroy: yay!00:09
jfroyIt is Very Good™ not to have to type my svn passwords 3 times or more for operations on svn repositories (with my experimental bzr+keychain branch)00:11
jfroyNeed to get that out of experimental now :p00:12
lifelesspoolie: sorry, missed it00:13
lifelesspoolie: pls ring again00:13
jfroyVerterok: It's kind of sucky that you have to maintain two builds to target 1.4 and 1.500:13
Verterokjfroy: yeap, don't have an idea of how much I agree on that00:14
jfroyTiger is so long ago for me, was svn even bundled with it?00:14
Verterokjfroy: but I know there are a lot of people still on 1.4.x00:14
Verterokjfroy: nope, you must install it from "somewhere" (macports, collabnet, etc)00:14
jfroyVerterok: that's incredibly crappy :/00:18
Verterokjfroy: yeap, that's the reason I only build it against collebnet binaries :)00:19
jfroyHonestly, I'd just make 2 packages, one for svn 1.4 and one for svn 1.5, installed in /usr/local/ (e.g. the collabnet binary packages). If they have it elsewhere, I'd just tell them to build bzr-svn from source...00:19
Peng_Eek, there's a test that builds everything?00:19
Verterokjfroy: imagine building it for macports, fink, collabnet (all x2 (1.4 amd 1.5)) :p00:20
jfroyVerterok: no thanks ;p00:20
Verterokme neigther :)00:20
jfroyIf you wanted to be *reaallly* clever, you could build against 1.4 only in /usr/local, then use an installer script to find the actual install, then muck around the Mach-O headers to change the import paths, and hoping the 1.5 libraries are binary compatible with the 1.4 libraries :p00:21
jfroySounds like a lot of unpleasant installer script work :p00:21
Verterokindeed :p00:22
jfroyVerterok: oh, you'd also have to weak import all symbols and modify the bzr-svn source to check for NULL function symbols, in case someone decides to build from source and omit support for https, or keychain, or what have you :p00:23
Verterokjfroy: that sounds way too complicated :), I'll stick with the script that build both version against collabnet binaries. as far I know, is the more complete dmg for 10.400:25
Verterokif someone builds svn from source, I'm pretty sure the 'll be able to build bzr-svn ;)00:26
jfroyVerterok: I wasn't being serious :p00:26
Verterokjfroy: I supposed that, but just in case :)00:26
=== jamesh_ is now known as jamesh
pooliemarkh, could you try to build 1.7.1 exes sometime?03:08
pooliei did not set up that server yet03:08
pooliei'd like to03:08
markhpoolie: sure - I'll try and do that this afternoon03:09
markhI've been working on porting pywin32 to py3k recently - that is an interestng experience :)03:11
markhwell - more like watching/helping some other person do it :)03:12
markhI figured I should get a little hands-on experience before the first official release - even if only by a few days03:12
jmlspiv: is there a config option I can use so that -dHPSS is always on?04:00
spivjml: "alias bzr='bzr -Dhpss'" in your bashrc ;)04:16
jmlincidentally, MemoryTransport.rename's behaviour varies based on dict ordering.04:21
spivjml: that doesn't sound good.04:26
jmlspiv: it doesn't feel good eiter.04:26
mwhudsonin other sucky news04:27
mwhudsonmwh@grond:init-stack-pull$ bzr push04:27
mwhudsonUsing saved push location: bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/init-stack-pull04:27
mwhudsonbzr: ERROR: Must end write group before releasing write lock on KnitPackRepository('bzr+ssh://bazaar.launchpad.net/%7Emwhudson/launchpad/init-stack-pull/.bzr/repository/')04:27
spivmwhudson: pastebin the traceback?04:28
mwhudsonspiv: there is no traceback04:28
spivmwhudson: ~/.bzr.log is your traceback-recording friend! :)04:29
mwhudsonhey guess what guys!!!04:29
mwhudsonit was autopacking04:29
spivIt might be caused by the same sort of situation that has caused TooManyConcurrentRequestErrors in the past.04:29
jmlnumber one bzr bug04:29
mwhudsonat least it's fixed now04:30
spivmwhudson: I'd still like to see the traceback :)04:30
mwhudsonspiv: https://pastebin.canonical.com/9805/04:31
mwhudsonspiv: happens with bzr.dev 3731 too fwiw04:32
spivYeah, I think it does have the same root cause.04:32
spivmwhudson: thanks04:32
mwhudsonmy bzr.dev may be a little out of date tho04:32
jmlspiv: bug 276972 if you are interested.04:33
ubottuLaunchpad bug 276972 in bzr "MemoryTransport.rename behaviour varies with dict ordering" [Undecided,New] https://launchpad.net/bugs/27697204:33
spivjml: ta04:39
mwhudsonspiv: happens with bzr.dev too, but maybe upgrading the bzr on the server would fix it?  not sure04:44
mwhudson(as would maybe pushing over sftp i guess)04:44
spivmwhudson: depends on what the underlying error that is being masked by the bug in BzrBranch.push is04:46
spivmwhudson: I can give you a patch to allow the original exception to propagate04:46
mwhudsonspiv: i am driving several hundred km away in about 20 mins :)04:47
spivmwhudson: http://rafb.net/p/4pgIvJ66.html04:47
spivmwhudson: but if you go enjoy your road trip instead I'll understand :)04:48
spivmwhudson: https://bugs.edge.launchpad.net/bzr/+bug/23090204:55
ubottuLaunchpad bug 230902 in launchpad-bazaar "BzrError: Must end write group before releasing write lock on KnitPackRepository" [Undecided,Confirmed]04:55
lifelessspiv: ping; remind me - subclasses of classes with slots; need the total list of attributes?05:28
spivlifeless: IIRC, they just need the list of attributes added by the subclass.05:28
spivHmm, apparently my memory is faulty.05:29
lifelessspiv: :P05:31
spivAh, no, just my quick 10-second attempt to verify it in the python interpreter was wrong :)05:32
spivMy memory turns out to be fine :)05:32
spiv(And the docs in fact say the meaning of defining the same slot twice, i.e. in a class and in a subclass, is "undefined")05:35
* mwhudson off05:43
lifelessspiv: interesting; see, I want to delete a slot the base class has :P05:52
spivlifeless: ah, well... tough :P05:56
lifelesswhen did I last mention hating doctest?06:05
lifelessabentley: are you up?06:07
lifelessserializers are puzzling me06:08
lifelessI'm hacking on a demand-loading inventory06:08
lifelessserializer foo currently assumes you *can* serialize an inventory to a single string06:08
lifelesse.g. bzrlib/tests/per_repository/test_repository.py06:08
lifelessline 671,06:08
lifelesswhich checks that the serializer is used and its sha output recorded06:09
lifelessI *think* I need to make the interface tests not be defined in terms of the serializer object, but I was wondering if you had any thoughts?06:10
abentleylifeless: by demand-loading, what do you mean?  Segmented so that only some items are loaded at a time?06:10
lifelessabentley: yes06:10
lifelessabentley: fragemented into lots of little pieces06:10
abentleySo I would say the serializer abstraction doesn't make sense for these.06:11
lifelessI figure I can have a serializer object that represents the particular style of splitting06:11
lifelessand we still have revisions as single objects06:11
abentleyOkay, our *current* serializer abstraction doesn't make sense.06:12
lifelessthanks, I think I have what I need06:12
lifelessI've posted about this work btw, and its pushed06:12
lifelessthe most recent stuff isn't passing tests yet and I'm closing the gap there hoping to push more to play with tonight06:13
abentleyYou'll probably want moral equivalents of most of the single-string serializer tests.06:13
abentleyAnd I'd imagine the existing tests should be used for existing serializers.06:13
abentleylifeless: Yeah, I sort of read it.06:14
poolielifeless: i don't have a strong opinion that you should do a cache in a CHKInventory now06:14
poolieit is not very clear from your mail why you'd want to06:14
abentleyI'm not really clear on what CHK stands for, so I can't comment intelligently.06:16
lifelessabentley: its an abbreviation for content hash key; e.g. "md5:1234123421342" or "sha1:1234135143514645acdef"06:16
lifeless(this predates git's terminology and is more general, I think its a more useful way to talk about using hashes as keys)06:18
abentleylifeless: So CHK is a superset of content-addressible filesystem.06:18
lifelesspoolie: there may be code that does lots of repeated lookups of the same fileid06:19
lifelesspoolie: a cache would ameliorate those codepaths (remove repeated-parsing overhead)06:19
pooliei thought that's what you meant06:20
lifelessabentley: roughly yeah; not really a file system as packs are transactional etc etc06:20
abentleylifeless: I mean the CHK terminology, not your work specifically.06:20
lifelessabentley: the yes, though I think perhaps 'intersecting with' rather than 'superset', but perhaps I'm being overly pedantic06:21
poolieabentley, i agree, i think HashKeyedInventory or something would be clearer06:22
poolieor even just HashedInventory06:22
poolieat least it's not scatalogical06:23
abentleyYeah, HashedInventory is more evocative.06:23
lifelessits building on CHKMap not on hashing itself; its quite generic code; uhm, I'm sure thenaming can be improved, but perhaps its making the layers clearer that is needed06:24
abentleyThis is also a split inventory concept.  Is it splitting on directories or a radix tree?06:25
lifelessabentley: either06:25
lifelessabentley: I intend to put together CHKMap subclasses to let use experiment with both both those concepts and the other variations06:25
lifelessabentley: (which are the parameters I mentioned in my mail from tuesday)06:26
pooliepresumably both of them should be renamed if we think 'CHK' is cryptic06:28
abentleylifeless: I didn't see that mentioned in the email.06:29
lifelesspoolie: presumably; one more note on naming though - it should be quite specific; 'Hashed' is IMO hopelessly generic, I mean, current Inventory objects are Hashed internally. (self._byid).06:29
spivI didn't find "CHK" too cryptic, but perhaps I'm just odd :)06:30
lifelessabentley: this list:06:31
lifelessThe undecided aspects, which experimentation/modeling is needed on:06:31
lifelessincludes the item for how we break up nodes in the tree06:31
abentleylifeless: It doesn't actually say that, though.  I had to re-read it 3 times to guess that "should we canonicalise nodes by size rules, or (only applies to a name map that doesn't hash keys) by directory membership" was addressingthat.06:34
lifelessabentley: sorry :)06:35
lifelessabentley: I'm quite deeply embedded in this now, after some months of lead up; I'll try to be more clear in future06:35
lifelessabentley: though there is a tradeoff in repeating content from the design work (which is in doc/developers/inventory.txt in bzr.dev)06:36
abentleylifeless: Yes, there is a balance to be struck.06:42
lifelessabentley: I just an image of a set of scales being hit repeatedly06:44
lifelessabentley: :)06:44
=== cody-somerville_ is now known as cody-somerville
markhpoolie: uploaded06:53
pooliemarkh, could you send me a brief roadmap of what you'd like to do next on tortoise?06:57
vilahi all07:03
vilaspiv: any reason you didn't re-vote on 'regression on OSX in TestReadMergeableFromUrl.test_smart_server_connection_reset' ?07:17
lifelessspiv: ping07:25
lifelessspiv: I have a wtf moment in check07:25
lifelessspiv: in repository.py, line 3259 for me is:07:25
lifelessknit_parents = parent_map[key]07:26
lifelessthis is in a try:except RevisionNotPresent: guard07:26
lifelessbut parent_map is a plain dict ?07:26
* spiv opens it up07:26
spivlifeless: sure looks like a wtf07:27
lifelessspiv: clearly, I'm doing heart surgery here, so I'm seeking option numero duo07:27
lifelessspiv: ok, so its broken code, and the question is 'why do normal repos not hit it'07:27
lifelessspiv: thanks07:27
spivlifeless: I assume there's a gap in the test coverage :(07:27
lifelessspiv: possibly not07:28
spivlifeless: hmm, actually07:28
lifelessspiv: possibly its a redundant check that cannot trigger unless something else is broken07:28
lifeless(as in some other code is broken)07:28
spivlifeless: yeah, that's what I'm suspecting07:28
spivlifeless: anyway, no need for us both to do the same digging at the same time :)07:28
lifelessspiv: I'm not digging at that :)07:29
lifelessspiv: with consensus on the wtf, I'm ignoring it07:29
spivAh.  Well, I still intend not to get side-tracked then :P07:29
lifelessspiv: good choice :)07:29
spivvila: oh, I didn't re-read the new patch carefully, I thought it was just updating == to is.  I see now it also moved it to the right layer.07:30
poolielifeless: did you call?07:30
lifelesspoolie: no07:30
spivvila: it'd be nice to have a test that reliably fails (on all platforms) without this fix.07:31
spivvila: I *think* that's probably feasible using the _DisconnectingTCPServer in test_bundle (i.e. the same way that is triggering test failures for you atm)07:33
vilaspiv: I'll look into that, do you also want it to apply to all SmartMedium classes ?07:33
vilawell, may be not all, the pipe one may not be relevant07:34
spivvila: e.g., start a _DisconnectingTCPServer, create a SmartTCPClientMedium pointing at it, and then try client_medium.read_bytes(1)07:34
spivWell, it'd be good to have equivalent tests for all SmartMedium classes, but it can't be the exact same test.07:35
spivPipes don't talk to sockets and get socket.errors, after all :)07:35
jdrakebzr is *sweet*07:36
vilasure, and socket.error may not be relevant either for http07:36
spivI certainly wouldn't object to doing that :)07:37
vilaspiv: Ok, I read that as BB:resubmit then :) Thanks07:38
spivBut I wouldn't hold up landing the fix to this medium while working on unique tests for all medium implementations.07:38
spivSo, bb:tweak :)07:38
jdrakeI can actually remember how to use some of the commands, unlike cvs07:38
spivjdrake: that's because we don't use "update" to do three different operations ;)07:38
jdrakeI might actually be able to use bzr to do more than just code with school coming up.07:39
spivvila: bb:tweak formally given07:40
vilaspiv: ok, thanks07:42
lifelessabentley: if you're around, do you remember the precise in-memory difference between a rich-root inv and a non-rich-root ?07:43
lifelessabentley: actually, nvm, asking that question clued me in to the answer07:43
robstahi lifeless07:43
robstalifeless: jelmer hinted you might know a workaround for phantom references messing up "diff"07:44
robstaoh "ghost revisions" it's called07:45
lifelessrobsta: hi; uhm, I don't think I do07:46
lifelessrobsta: did he hint with any more detail ?07:46
lifelessjelmer: ^ EWHYME?07:46
robstalifeless: no; is this specific to svn server-side?07:46
lifelessrobsta: yes, bzr-svn exercises the ghost capabilities most strongly of anything bar 'baz-import' which I think has actually been deleted from bzrtools now07:47
lifelessrobsta: last I heard jelmer was working on changing a bunch of stuff to fit what bzr's core looks for more; I don't know  if he has07:48
lifelessrobsta: BTW, orthogonal thing, you might like to try the 'development2' format in bzr.dev; it uses the btree stuff I was doing back @ guadec; the new compressor isn't finalised yet, but the index stuff helps quite a bit07:49
robstalifeless: define "quite a bit"07:49
robstalifeless: i tried going back to bzr-playground.gnome.org, but when i merge my svn into the bzr branch there's an error about rich-root07:50
lifelessrobsta: depending on specific workload, up to 10 times faster, or more.07:50
lifelessrobsta: pastebin the rich root error please07:50
robstaspeed is not the problem, the problem is that diff bails on me07:51
lifelessrobsta: right, did I mention orthogonal?07:51
robstalifeless: http://pastebin.com/m36aec88007:54
* robsta prefers to stay one-dimensional07:55
lifelessthat would be the whiskey dimension?07:55
lifelessrun bzr info -v locally please07:55
lifelessspecifically on gtk-css-engine-bzr07:55
lifelessno idea *how* you got that setup; but its not a bzr-svn compatible local repository07:57
lifelessback it up, then bzr upgrade --rich-root-pack07:57
lifelessthen try again07:57
robstalifeless: yay07:58
robstalifeless: so does this still have ghost references, or can i push --overwrite this to the upstream svn?07:58
lifelessrobsta: give it a shot; I disclaim all knowledge of code internals07:59
lifelesssvn is atomic yeah? whats the worst could happen :P07:59
poolievila, yeah, let's talk here08:00
vilaDiscussing with John, it appears that log.py miss an API with revids (that's the main blocking part for missing)08:00
vila<vila> either that or some variation where you give the list of revisions you want to show08:01
vila<vila> roughly speaking, log is designed around revnos with shortcuts to avoid O(history) when only mainline revisions are needed08:01
lifelessvila: ^ oh yeah, re ghosts, bzr-svn, major user.08:01
vilalifeless: thanks, sorry, I still need to send that mail :-/08:01
vilalifeless: but it's not forgotten !08:01
robstalifeless: "No new revisions to push." can i force this somehow?08:03
robstalifeless: for some reason svn is like 30 revs ahead08:04
vilaI (well jam too :)  think log.py should evolve in a direction where we can calculate revnos on-demand08:04
poolievila, i think that idea of jam's that we should show why some revisions are included is interestning08:04
poolie> the true solution is to be able to get revnos without being O(history)08:04
poolieright, that would be highly useful08:05
vilasure, the two are related, but getting revnos without being O(history) is the root08:05
poolieso as i understand there are two threads towards that - either caching them, or looking for algorithms that let us skip larger parts of the graph08:05
vilaanother one being changing the revno definition, but for compatibility I don't want to *start* with that08:06
vilaan intermediate solution is also to use gdfo08:06
vilagdfo == Greatest Distance From Origin08:07
vilawhich could also help spiv case in Batch get_parent_map HPSS calls made from InterRepo._walk_to_common_revisions08:07
vilaI know that but I'm not able to explain it clearly just yet :-/08:08
vilaroughly, we indirectly batches requests when bisecting today, using gdfo can help batching requests in a more controlled way08:08
lifelessrobsta: svn has new content?08:09
lifelessrobsta: or just a higher 'revno' ?08:09
robstalifeless: just revno, just pulled everything into the bzr tree08:09
lifelessrobsta: revno is per-branch, so it sounds like no-problem to me, or am I missing something?08:10
poolievila, so as far as scheduling it, i'd be looking at: is it likely you'll make progress on it, does it matter to guilhem and other users, and should we be concentrating on something else instead08:10
pooliei would say the startup overhead for log does matter to people08:10
lifelessrobsta: I have to go now; sorry08:11
lifelessrobsta: uhm, I'd hope jelmer is up soon08:11
vilaI'm surely making progress on it but I need some more time to show results08:11
lifelessbye poolie08:11
lifelessand vila etc08:11
robstalifeless: will use it, should work, thanks!08:11
vilathe scale being days08:11
poolienight lifeless08:11
vilalifeless: cu08:11
vilathe scale being days, several days, but not more than two weeks I'd say08:11
fullermdWell, on the downside, getting log running IS awfully slow sometimes...08:11
fullermdBut on the sorta-upside, any time I feel like log is too slow, I can just run log -v to jolt myself.08:12
vilaanother aspect, thanks fullermd, is to make log really streamed08:12
fullermdWe're storing the revno of HEAD in the branch.  I can't help but feel we're not USING it, though...08:13
vilaanother option being to *not* show revnos for people who want really fast log :)08:13
* spiv goes to the shops08:13
vilafullermd: we use it !08:13
vilaall shortcuts are based on that08:13
poolievila, or we could default to log --line, and make sure that it does not compute non-mainline revisions08:13
pooliei think that may be the easiest in some ways?08:13
vilapoolie: I think we do already08:13
pooliedo you know what's the main thing in the profile of --line?08:14
fullermdThat's even sadder, then.08:15
pooliewell, perhaps that's beside the point08:15
pooliefullermd: what is?08:15
fullermdlog --forward --short -r-10.. of bzr.dev (with bzr dev), with all the caches heated up and all, takes like 3 seconds.08:16
vilaI concentrate on higher level stuff so far but plan to measure progress on how things go08:16
fullermdI assumed at least some of that was eaten up walking back to origin to figure out the revnos.08:16
pooliehm, it's about 800ms for me...08:16
fullermd2.608u 0.223s 0:02.84 99.2%08:17
vilafullermd: come on, --forward is just asking for slowness :)08:17
vilaat least for now08:17
fullermdDoesn't make any distinguishable difference   :p08:18
vilaroughly, actually, log is based on the idea that we built the history we need (the long part) then we issue the formatted text we want for each revision08:18
fullermdNow, granted, my system isn't the speediest on the planet.  But still, it's fast enough that Firefox is almost usable a good half of the time.08:18
vilaWhat I'd want to do is make it more streamed: walk the needed graph, filter revisions, display formatted text08:19
luksjelmer: are you around?09:09
pooliehi luks09:21
luksok, now I'm really confused09:41
luksI thought `bzr dpush` from bzr-svn was supposed to rebase my branch09:41
luksbut it kept my bzr revision untouched, so I deleted the bzr-svn cache, tried to branch again and I still get the original revision09:42
bob2hm, so long since I modified a chatscript10:00
No`hi bazaarians10:07
jelmerluks, somewhat10:15
jelmerluks, it will rebase your *local* branch10:15
jelmerif necessary10:15
luksjelmer: yeah, the thing is that it did not10:16
luksjelmer: at least from what I can see10:16
luksjelmer: and I don't understand where is the info (revid, etc.) stored, because it's not in SVN10:16
jelmerluks, it will also not rebase if it didn't have to push anything10:16
luksjelmer: it pushed one revision, I'll try to branch on a completely clean machine10:17
lifelessjelmer: robsta has some issues10:17
robstalifeless: should i attach the repo tarball to the bug (1.7M bz2) =10:20
lifelessrobsta: sure10:20
lifelessjelmer: I am not here right now, but all I had robsta do was upgrade to rich root (they weren't, for some ??? reason - don't know how anything had worked before then)10:21
lifelessjelmer: but now it has a missing text error, I'm suspecting some bzr-svn interaction bug; perhaps you can chat in detail with robsta to figure out exactly what's happened10:21
robsta#277043, fyi10:23
Se6astHi guys. I do have a small project versioned with bzr (personal version control in the guide), myproj/subprojA. so in subprojA there is a .bzr repo with the full history. However, I am now adding other sub-projects: myproj/subprojB, myproj/subprojC and I would like to have a new bzr repo with everything in myproj. So I cd myproj; bzr init. How can I pull all the versioning history of subprojA into it ? with merge? in myproj if I do bzr merge subproj10:26
jelmerlifeless, robsta: I don't have time to look into it at the moment, but have a look when I do. Thanks for filing a bug.10:27
jmlis there a revisionspec for branch parent?10:54
visik7I want to checkout django-1.0  with bzr11:03
visik7bzr get http://code.djangoproject.com/svn/django/trunk django-bzr11:03
visik7 bzr get http://code.djangoproject.com/svn/django/tags/releases/1.0 django11:04
visik7the 2 path works with the svn command11:04
lifelessjml: :parent ?11:22
jmllifeless: nope. maybe my bzr is too old.11:22
lifelessoh thats a location alias11:23
liwif I convert my branch to rich-root-pack format, how likely will I make other people suffer? (the main person I collaborate with has that format and that makes it hard for me to currently accept his bundles)12:14
=== bac_afk is now known as bac
=== kiko_ is now known as kiko
g0nzal0hi there!15:43
g0nzal0I'm trying to use bzr-svn15:43
g0nzal0I installed it using "sudo easy_install bzr-svn"15:43
g0nzal0but it doesn't seem to be working :(15:43
Verterokg0nzal0: what is the name of the directory were easy_install "installed"?15:58
Verterokohh eggs15:59
Verterokg0nzal0: I'm not sure that bzr  plugins work as eggs at all16:00
g0nzal0I see, I'll try something else, thanks for the info :)16:00
Verterokg0nzal0: try installing it using plain old setup.py and avoid egg16:00
g0nzal0yes, I'm onto it16:00
Verterokg0nzal0: np16:01
=== alperkanat is now known as alperkanat|away
g0nzal0Verterok: :(16:05
=== alperkanat|away is now known as alperkanat
Verteroklet's see16:12
Verterokg0nzal0: run it with -Derror16:12
Verterokg0nzal0: i.e: bzr -Derror plugins16:13
g0nzal0Verterok: I had bzr installed with easy_install too16:18
g0nzal0Verterok: took that away16:19
g0nzal0Verterok: and reinstalled it from ppa16:19
g0nzal0Verterok: (I use Ubuntu)16:19
g0nzal0$ bzr -Derror plugins16:19
g0nzal0gtk 0.94.016:19
g0nzal0    Graphical support for Bazaar using GTK.16:19
g0nzal0    Launchpad.net integration plugin for Bazaar.16:19
g0nzal0svn 0.4.1316:19
g0nzal0    Support for Subversion branches16:19
Verterokg0nzal0: goooood, ppa is goood :)16:19
g0nzal0didn't know about it, it rocks! :)16:20
=== alperkanat is now known as alperkanat|away
vilala la la, Russian roulette, pqm blocked16:23
g0nzal0I'm branching django-survey with bzr-branch!!!16:23
=== BasicPRO is now known as BasicOSX
jamvila: *why* does it always happen from *your* submissions?16:27
jamI'm really quite surprised16:28
jamI wonder if it is merging from lp: that is causing problems16:28
vilaI had one submission passing without problem from lp earlier16:28
jammaybe it doesn't like "osx" in names16:29
vilawhat surprised me the most is that the submissions are successful while someone is *killing* a process (knowing what process may help though)16:29
jamvila: I just pinged mthaddon, and he said he got it going again16:30
vilathanks to him and you, again...16:30
vilaMost probably, bugs are a big family and some vendetta is going on each time I fix a nasty one :)16:31
=== alperkanat|away is now known as alperkanat
=== alperkanat is now known as alperkanat|away
=== alperkanat|away is now known as alperkanat
=== kiko is now known as kiko-fud
_MMA_Command to upload *all* unknown files in a existing branch?18:05
_MMA_bzr add ?18:05
beunodepends on your definition of *all*18:06
beunoadd won't add ignored files18:06
_MMA_Anything shown as "unknown".18:06
beunobzr add18:07
_MMA_Oh. I thought it had to have something after "add". Like "bzr add all" or something. :)18:08
beunonope nope, it's the default18:11
beunoyou have to add something if you *just* want to add one file18:11
_MMA_I see.18:12
=== rockstar` is now known as rockstar
=== kiko-fud is now known as kiko
idx_fooInstalling bzr for eclipse, I have bzr, jdk, eclipse and xml plugin of correct versions.18:49
idx_fooIn Window -> Preferences, turning on icon decorators causes "An error has occured. See error log for details"18:50
Verterokidx_foo: did you configured the bzr executable in Preferences --> Team --> Bazaar?18:50
idx_fooWhen trying to share a project, I choose a bzr path, click next, it flashes up a progress dialog very quickly, then does nothing.18:51
idx_fooVerterok: yes, to /usr/bin/bzr18:51
idx_foobzr works fine, and the --xml option does too.18:51
Verterokidx_foo: which version of bzr-eclipse and xmloutput?18:51
Verterokalso, what is the name of xmloutput plugin folder in .bazaar/plugins ?18:52
Verterok(it should be xmloutput)18:52
idx_foobzr eclipse 1.1.018:52
idx_fooI'll try that18:52
Verterokidx_foo: rename bzr_xmloutput_0_8_0 to xmloutput :)18:53
idx_fooNow the error doesn't happen in the pref window18:54
idx_fooBut still can't share the project18:55
idx_fooI'll be back later18:55
=== idx_foo is now known as idx_foo_away
Verterokidx_foo_away: when you come back, please check the log at <workspace>/.metadata/.log18:56
=== jfroy|work is now known as jfroy
Stavrosmy repo is in knit4 format and i need to upgrade, which is a good format to use?19:01
beunoStavros, packs 0.92 if you're not into any weird stuff19:01
Stavrosbeuno: does sodomy count?19:01
beunowell, weird is a very dodgy concept19:02
beunoI'd say, go with packs, and if something doesn't work, you can always change again  :)19:02
Stavrosthat doesn't work19:02
Stavrosbzr: ERROR: Cannot convert to format <RepositoryFormatKnitPack1>.  Does not support rich root data.19:02
beunorich root19:02
Stavrosand it broke my repo19:02
Stavrosgood thing it made a backup19:02
Stavroswhat's rich root?19:03
beunobzr makes backups when upgrading19:03
Stavrosi moved it back and it works19:03
Stavrosbut no upgrade19:03
Stavroswhy do i have this rich root?19:03
beunoStavros, I think you have to do bzr upgrade --rich-root-pack19:03
=== mw___ is now known as mw|food
Stavrosôçáô óååìó ôï çáùå òïñêåä, ôçáíêó19:04
Stavrosthat seems to have worked, thanks19:04
=== Verterok is now known as Verterok|out
nihilocratI'm having an issue with several of my projects... there are some files that constantly have conflicts (they are binary and necessarily changed every commit)19:09
nihilocratI solve them by just copying *.OTHER over the original file and resolving it19:09
nihilocratbut in some cases I am getting conflicts where it says some file called <filename>.OTHER.OTHER.OTHER<etc> is conflicted19:09
nihilocratI have no idea how that happens and how to get it to go back to just being <filename>.OTHER19:10
beunonihilocrat, are you running "bzr resolve FILENAME" after you copy the file over the existing one?19:10
nihilocrathere's what I usually do:19:11
nihilocratmv file.OTHER file19:11
nihilocratresolve file19:11
nihilocrat*bzr resolve19:11
beunoand then you commit?19:11
nihilocratthe mv is just normal old mv19:11
nihilocratno, I don't commit, usually it's the case where this is a working copy that I'm pushing to19:12
nihilocrat(web app code)19:12
beunoI see, the remote branch is the one with .OTHER.OTHER...?19:13
nihilocratusually I push, and then update19:14
nihilocratand then the conflicts appear19:14
beunoyes, that's happened to me19:14
beunoI'm not exactly sure why that happens (I should probably look into it)19:14
beunobut, what I have to do, is resolve them remotely, and commit19:14
nihilocratdue to annoying firewall configuration that can't be changed, I can't just bind to the master branch and update19:14
nihilocratI have to push19:14
beunoit only happens sometimes19:14
beunoso, I haven't needed to look into it too much19:15
=== idx_foo_away is now known as idx_foo
nihilocratI might try resolving, committing, then pulling19:15
beunoI'd also recommend running "bzr reconcile" on the remote branch19:15
nihilocratsee if it at least gets rid of OTHER.OTHER.OTHER19:15
nihilocratnever heard of that command19:15
nihilocratI'll look into it19:15
beunonihilocrat, make sure the remote repo is clean and resolved, commit, resolve19:15
beunoand pull19:16
beunoshould work well from then on19:16
idx_fooOk, so I'm installing bzr eclipse, but when I go to Team > Share Project, at the Select Directory screen, "Finish" pops up a progress bar that dissapeares quickly, and doe not xlose the wizard. The project cannot be shared as a result.19:16
=== Verterok|out is now known as Verterok
Verterokidx_foo: go to preferences -> team -> bazaar19:17
Verterokidx_foo: there is textfield to speficy the port of the xmltpc service, and just above it a label that indicate what kind of client was detected19:18
Verterokso far so good :)19:18
idx_fooRecheck changes nothing19:18
Verterokthat means that the xmloutput is correctly installed19:19
idx_fooBtw, before hand to check bzr from the terminal I did "bzr init" and then "bzr add somefolder"19:19
Verterokidx_foo: np, thanks ok19:19
idx_fooSuccessfully, but I don't know how  that will change Eclipse's behaviour19:19
Verterokidx_foo: please check the log file at <workspace>/.metadata/.log19:19
Verterokidx_foo: that should not affect eclipse19:20
Verterokidx_foo: of open the error log view if you have de SDK19:20
idx_foowhat SDK is this19:20
idx_fooI have .log open in gedit now, rather huge though19:20
idx_fooI'm getting "java.lang.NoClassDefFoundError: org/eclipse/jface/viewers/BaseLabelProvider"19:21
Verterokyeap, it grow and grow, until you zap it19:21
Verterokidx_foo: what version of eclipse?19:21
idx_fooOn Ubuntu 8.1019:21
idx_foo8.04 even19:21
Verterokbzr-eclipse only works with >= 3.319:21
idx_fooLets hope there's a deb of 3.3 somewhere19:22
idx_fooSo in other words Ubuntu's repository is rubbish19:22
idx_fooSorry about that, must have skimmed over the Eclipse req.19:22
Verterokidx_foo: I don't think so :(, but installing eclipse is just unzip/untar the archive19:22
Verterokidx_foo: I think all debian based distros lacks an updated eclipse19:23
Verterokidx_foo: np :)19:23
Verterokidx_foo: there is Bug #12306419:24
ubottuLaunchpad bug 123064 in eclipse "Upgrade to Eclipse 3.4.1" [Wishlist,Confirmed] https://launchpad.net/bugs/12306419:24
idx_fooAny other good IDEs with bazaar integrated?19:25
idx_fooFor Linux that is19:25
Verterokidx_foo: just download the lastest version from eclipse.org, unzip and run :)19:28
Verterokidx_foo: I think gedit is integrated with bzr19:28
beunoidx_foo, https://edge.launchpad.net/bzr-gedit19:28
beunohi Verterok19:28
Verterokidx_foo: also, PIDA for a list of all: http://bazaar-vcs.org/IDEIntegration19:29
Verterokbeuno: hey there!19:29
=== jelmer is now known as Guest30327
idx_fooWorking fine now. Thanks for the help Verterok19:30
Verteroknp :)19:30
idx_fooI just hope this is sufficiently different/better than svn to warrant the switch19:30
* Verterok invites idx_foo to file bugs as he encounter them :)19:31
idx_fooBut is failing miserably when installed on the wrong version of Eclipse a bug, or a deterent? :)19:31
Verterokidx_foo: bzr-eclipse is under active development, but the basic workflows are covered19:31
Verterokhe left :p19:33
=== Verterok is now known as Verterok|out
rockstarjam, want to do TWiB in an hour?19:39
=== Guest30327 is now known as jelmer
jelmerrockstar: hi20:19
persiaHi.  I've started to use bzr a lot lately, and wanted to ask about the chances of a much more stupid algorithm for pulling/pushing/merging to help speed up my use case.20:20
jelmerhi persia20:20
jelmerpersia: what's your use case?20:20
persiaHi jelmer.20:20
persiaI've *lots* of bandwidth (gigabit fibre ethernet to the international routers), but also lots of latency (about 150-200ms to launchpad).20:21
persiaFor protocols like FTP and HTTP, I get to take advantage of increasing TCP windows, and get lots of packets in flight.20:21
persiaThis means I get to use 2-3Mbps of bandwidth at that latency.20:22
persiaFor bzr, it seems there are *lots* of little transactions, trying to save me bandwidth, but each one starts with a small TCP window, and with my latency, it makes it *very* slow.20:22
persiaSo, what I'd like is some switch I can pass to tell bzr to be stupid, and just grab the entire repo on the other end as one big upload/download, and then process it afterwards.20:23
jelmerpersia: there's a lot of incremental work going on trying to reduce the number of round trips20:23
persiaOK.  That helps some.  Is that related to work to make it push more per trip?20:24
beunopersia, one thing to make sure is that you're using packs format (you probably are if the repos are new enough)20:24
persiaUnless I'm downloading a few megabytes, I haven't a chance of reaching reasonable transit speeds.20:24
jelmerpersia: for the smart server, yes20:24
jelmerpersia: for FTP and HTTP a flag like the one you describe could indeed help20:25
jelmer(I'm in the same situation btw, although my latency isn't as bad as yours)20:26
persiaWell, generally, those are just one big file.  websites that have *lots* of little files to try to make it feel faster for people with low bandwidth or low latency are slow for me though.20:26
beunopersia, the core devs are almost all in australia. That puts their focus on latency quite a lot  :)20:27
persiaYeah.  My combination of bandwidth and latency seems to be a corner case, and as I've spent 3 hours waiting for bzr to do stuff today, I figured I'd come by and see if I could publicise my use case to make it faster.20:27
beunothe flag for bigger chunks in http/ftp does sounds interesting20:28
persiaWell yes, but the situation in Australia is different: nobody has much more than maybe 10Mbps there, and the undersea trunks are usually congeste.20:28
beunopersia, feel compelled enough to start a thread in the mailing list?20:29
persiaSo they focus on latency, but can't take advantage of TCP windows like here or in Korea.20:29
persiabeuno: I could, if it's likely.  I don't know how many bzr LP users are in Japan or Korea, and I don't think this environment is common anywhere else.20:29
persiaAlso, what's the mailing list?20:30
persiaOK.  Is there likely to be space in the development queue that optimising for such a situation is likely, or is it more interesting to focus on other use cases for now, and I should test again with 1.7 or 1.8 and start a thread then?20:32
persia(feel free to remove any duplicate words when parsing)20:32
=== alperkanat is now known as alperkanat|away
beunopersia, speed is the main focus ATM I believe20:36
beunoso this sounds entirely appropriate20:36
persiaOK, then adding my use case is probably worthwhile.  I'll send an email during my next pause.  Thanks :)20:37
=== alperkanat|away is now known as alperkanat
=== mark2 is now known as markh
pygihi hi20:46
AmanicAI made a super cool linux startup script for loggerhead today. Do markh/beuno think I should make a branch/patch adding it to the mainline?20:49
beunoAmanicA, merge proposal!20:53
beunoyes  :)20:53
AmanicAbeuno, like in branch or like in bundle?20:53
beunoAmanicA, branch20:54
beunoand file a merge proposal in Launchpad20:55
AmanicAbeuno, atm I call the script loggerheadd  (the double dd is not a typo) and I added it to the root. is that ok?20:55
AmanicAbeuno: cool will do. hope I dont overhelm you guys, but I was itching a lot this week :)20:55
beunoAmanicA, I'd try and name it something less confusing  :)20:56
beunoand, the rest you can get from the review20:56
beunoAmanicA, we *love* contributions20:56
AmanicAbeuno: any ideas?20:56
=== alperkanat is now known as alperkanat|away
beunowe sometimes suck on responding in a proper time frame, but we really love 'em20:56
beunoAmanicA, what does the script do exactly?20:56
AmanicAits a /etc/init.d script20:57
AmanicA(and lots of them end in d for daemon)20:57
beunoI see20:57
beunohm, tough call20:57
beunoI'd say, file it as "noname", and we can go through it during the review20:57
AmanicAah, then I can tust leave it like is, and if the reviewer have a bettername, we can update it :P20:58
AmanicAany idea when launchpad will support stacking properly? as its a bit of overhead to upload branches for single file changes..21:00
beunoAmanicA, well, it sort-of does now21:00
beunoif we upgrade the loggerhead branch to 1.6 format21:01
beunoyou should be able to stack21:01
AmanicAoh, so not ATM :(21:01
beunolet's wait for mwhudson to come by, and ask him if he's cool with that21:01
AmanicAno rush, I just wondered21:01
beunowell, I've stacked things21:01
AmanicAloggerhead is luckily small21:01
beunoit has some gotchas21:01
beunobut it works21:01
beunoand I'd love to have more people test it21:02
AmanicAI'm thinking uploading bzr branches could get hecktick21:02
AmanicAbzr i.e. bzr.dev.my_fix etc.21:03
beunoyeap yeap21:03
=== mw|food is now known as mw_______
beunoit's going to be very usable very soon21:03
AmanicAcan hardly wait:)21:04
=== mw_______ is now known as mw_________
blueyedjelmer: about bzr-shell-hooks: do you think it makes sense to chdir() to the branch root, before executing the command?21:05
=== mw_________ is now known as mw|out
jelmerblueyed: sure21:08
=== mw|out is now known as mw
blueyedjelmer: how do I get the directory from branch? (or the other way around: can you just add it? :))21:09
=== alperkanat|away is now known as alperkanat
jelmerblueyed: branch.base IIRC21:16
uwswow, bzr is quite fast!21:17
uwscommitting 2000 new files takes only a few seconds21:17
uwsi now use it for "scratch" version control. putting temp data in bzr, and removing .bzr once in a while if i made sure I didn't screw up :)21:18
blueyedjelmer: yes. and then, I should probably not use urlutils._posix_local_path_from_url directly?!21:20
rockstarjelmer, hi back (sorry, went out to eat some lunch)21:21
jelmerblueyed: branch.transport.local_abspath(".") should work I think21:22
jelmerrockstar: I've finished exporting the bindings of bzr-svn - https://edge.launchpad.net/subvertpy21:23
rockstarjelmer, you used the name!  Yippee!21:23
* rockstar feels like he contributed.21:23
blueyedjelmer: great, it works. I'll add that only for the "local" part, i.e. if branch gets set to "local", not when it gets set to "master".. I suppose the latter is for remote operations?!21:25
jelmerblueyed: no, it's for checkouts21:25
blueyedjelmer: ok, so I'll add it for both cases.. however, only when branch.transport is given. Since, on "uncommit" it isn't given..21:29
blueyedthe backtrace then: http://pastebin.com/m6dd9b59e21:29
jelmerblueyed: try branch.bzrdir.root_transport instead21:31
AmanicAsheweet, I made the loggerhead top five contributers list!   (without even trying)21:33
rockyjelmer: now you just need to convert trac to use it ;)21:37
AmanicArocky: :) yup (you know Ive made a gforge plugin which uses)21:39
rockyAmanicA: hmmm?21:39
blueyedjelmer: works better. now I'm wondering why 'pre_commit = sh -c "echo \$4 > blogs/inc/_revision.inc.php"' results in 'bzr: ERROR: [Errno 2] No such file or directory'.. something simple like "echo" works..21:41
jelmerrocky: it can already do that through trac-bzr and bzr-svn ;-)21:47
rockyboo =P21:47
jelmerblueyed: not sure if that escaping will work ok21:48
blueyedjelmer: ok, that's a problem with subprocess.call, which uses the whole command as-is (and it does not exist), would have to pass ["sh", "-c", "..."] + args21:48
blueyed..but cannot put that in the config (as list)21:49
blueyedjelmer: it would work with shell=True for subprocess.call21:57
=== ndim_ is now known as nidm
=== nidm is now known as ndim
jampersia: still around?22:14
jamThere may be a somewhat trivial hack you can do to rebalance one of our algorithms22:14
persiajam: That's exactly the sort of thing I hoped was true :)22:14
jampersia: bzrlib/transport/http/__init__.py22:14
jamaround line 34422:15
jamis "recommended_page_size()"22:15
jamwe currently set it to 64kB22:15
lifelesspersia: we should be keeping one tcp connection open22:16
lifelesspersia: what protocol are you using?22:16
persialifeless: No idea.  I do bzr branch lp:... and bzr push lp:...22:16
persiajam: SO I could just bump that to a couple megabytes, and I'd be happy?22:17
lifelesspersia: if you've authenticated, and you probably have both will be over bzr+ssh22:17
lifelesspersia: so per bzr command the windows should be expanding as normal; modulo ssh window bugs (have been before, bet there will be again)22:17
lifelesspersia: if you're running lots of commands, try setting up a master control connection which may help the windows expand22:18
persialifeless: OK.  Then my guess at the cause is probably wrong.  Still takes *way* longer than it ought, and I thought my situation might be odd enough that a hack would help, when it wouldn't help others.22:18
lifelesspersia: it may be right; gather some stats:P22:19
persiaNo, I don't run lots of commands.  I branch.  I push.  I forget about it.  A few days later, I delete the cruft.22:19
lifelesspersia: I'm simply noting that we won't, per-command, be connecting many many times; 2 perhaps - directory lookup + ssh for data22:19
persialifeless: That's all?  Which version of bzr?  (I use 1.3)22:21
lifelesspersia: should be any for this use case22:22
persialifeless: OK.  Thanks.  I'll try jam's hack anyway, and see if it helps me.  Maybe I'm just confused.22:23
jampersia: well depends how you are connecting. my change won't effect bzr+ssh (as it only effects http)22:24
persiaOh, and I'm probably usually using bzr+ssh.  Oh well.22:24
jamYou might set the one in "bzrlib/transport/remote.py" though22:25
lifelessor you could try out a btree repo :P22:26
jamlifeless: I think btree would actually exacerbate his specific problem, as it doesn't have the concept of minimum request size22:26
jamwe haven't hooked in recommended_page_size() handling22:26
jamthough I think we could do so at logical-block partitions in the Btree index code22:26
jelmeris there some way to peek at the smart server commands?22:26
jamwhich avoids some of the inefficiencies in our current system22:26
lifelessjam: I don't think he's identified the problem, just assumed that his network configuration implied a specific issue22:27
jelmerwireshark doesn't work so well at ssh connections?22:27
jamjelmer: -Dhpss ?22:27
jamgives a log of every request22:27
jelmerjam: ah, thanks22:27
lifelessjam: and as such, any test that expands our knowledge is helpful22:27
jelmeryeah, the number of roundtrips with hpss is really bad :-(22:28
lifelessjam: specifically, btree does less roundtrips often just cause of the better fan-out22:29
persiaIf someone wants to prepare a test script that does stuff, I'm happy to run it against either hardy or intrepid, and return the results.  On the other hand, I don't understand most of the recent conversation, so wouldn't know how to produce useful test results.22:29
jelmerit's the limiting factor for me, git seems CPU-bound22:29
jelmerat least this explains why bzr-svn is faster than bzr+ssh for me22:33
lifelesspersia: don't worry about it; we are testing on high latency stuff at the moment22:36
uwssftp:// feels faster than bzr+ssh:// for me even22:37
uws(no numbers to confirm/deny this)22:37
uwsperhaps it's the overhead of starting a python process on my rather slow server22:38
persialifeless: OK.  I just fear you're not going to notice throttling with the congestion in the cables down there :)22:38
lifelessuws: could well be22:42
jamuws: I know spiv just introduced a patch which patches a hole in the bzr+ssh case for push and pull22:51
jambasically, while we are inspecting,sftp/http will download some searching for things that aren't there and cache it22:51
jambzr+ssh just returns an empty response22:51
uwsjam: care to elaborate on what "patches a hole" means?22:51
jamuws: "fixes an edge case" ?22:52
uwsoh, I thought "avoid the bzr startup overhead" :)22:52
jamso for push/pull we have to find out what each side doesn't have22:52
jamI guess for bzr+ssh if you have 50 new revisions it may actually send 50 requests and not get anything before it starts finding info22:53
jamwhile for http and sftp it will be filling in info about the indexes during that time22:53
jamwhich makes future correspondence faster22:53
jambasically, you can get 50 round trips with bzr+ssh that don't actually transmit any info22:54
jamwhich is a bit naughty22:54
uwsah, ok.22:54
jamwell, they transmit1 bit of info22:55
jam"not there"22:55
jamrather than 64kB of "not there yet, but here is some other info"22:55
jamI take it back, I reviewed it, but it hasn't landed yet22:56
jamlifeless: I'll note that Index *bandwidth* is the number one issue right now for me doing "bzr up" in my bzr.dev branch.22:59
jam(this is specific to my case)22:59
jamI haven't nailed down all the reasons yet22:59
jambut I have the feeling we have non-clustered revsion-ids22:59
jamlike "john@" and "pqm@"22:59
jamso it has to bisect a lot of the index, and it interacts in poor ways with the page expanding algorithm23:00
lifelessjam: right23:00
jamright now, if you make a request for 100-200, it expands to 100-6410023:00
jambut then if you request 50-100, it expands to 50-6405023:00
jamI'm thinking to not worry about it for GI, and just work on it a bit with the btree code23:01
lifelessjam: for sure23:01
jamBut it means the expansion needs to occur at the index layer, rather than the Transport layer23:01
lifelessjam: having figured out that GI couldn't be really fixed without disk changes, I'm not going to touch it again; it will just throw something else out to do so23:01
blueyedI want to have the revision/revno in a textfile inside the branch and tried the pre_commit hook for this, but the changed file gets not committed. Is this possible after all? (or would I need to do this during deployment and keep it out of the branch)23:02
jamblueyed: there is a "start_commit" hook which you could use, but you won't have the revision_id23:03
jam(I think)23:03
jamI don't know that there is a way to commit a file with the text of the revision_id to come23:04
jamit is possible in bzr's structure, but I don't think we expose a hook at the right time for it.23:04
lifelessand we shouldn't23:04
blueyedjam: start_commit isn't defined with the shell_hooks plugin23:04
lifelessits incompatible with the minimal contract for foreign branch commit support23:05
jamlifeless: I agree that not all foreign formats could support it. I don't think that should absolutely prevent us from doing it23:05
lifelessjam: it should at a minimum make us question very hard23:06
lifelessjam: I don't think its a good idea regardless of foreign formats23:06
jamit is similar in concept to $Keyword$ expansion, and has similar benefits and drawbacks23:07
blueyedlifeless: it would be really handy to provide a $app_revision variable (that's what I was trying to do), or add a suffix like "rXX" to a version number.23:07
jamI think some people would rather get extra conflicts at certain times23:07
jamthan not have the ability at all23:07
jamblueyed: you can always run "bzr version-info > my_file.txt" as part of a "build" process23:07
jamwhich is certainly the recommended way to do it23:08
=== fta_ is now known as fta
blueyedjam: yes, I know.. that's what I've meant with "deploying".. it's a php app after all and there's no "build" process (and also no "deploying" currently).23:08
* spiv hops on a train23:09
lifelessblueyed: doing that on tree building - checkout/pull - is much more reliable23:09
blueyedyes, I see. Thanks.23:09
jamblueyed: have you looked into what "bzr upload" supports? I haven't poked into that code, but it may be a good place to hook in that sort of work23:09
blueyedjam: well, I can see no hooks, but it creates a file .bzr-upload.revid, which could be used probably23:23
jamI'll also mention it is probably easier to get code into a plugin23:23
jamAs it has a smaller system-wide effect23:23
blueyedsure. It was only a nice-to-have idea, no problem.. :)23:24
beunoblueyed, it does have a tip-change hook to auto-upload23:24
beunoprovided by james_w in a patch  ;)23:24
jamblueyed: And on that note, you could use the "post-branch-tip-changed" hook to generate the file after commit23:28
jambut then the file isn't versioned.23:28
blueyedbeuno: well, looked in the released version (Intrepid) only.. but found it now.. that's different however (and it's hooking, not being hooked AFAICS).. but I get the idea, that a post-upload hook might get added to the plugin. However, the hidden file would be enough in my case23:28
beunoblueyed, it's in intrepid???  :)23:29
blueyedyes.. as with pre_commit.. that would be the whole idea however (and is why the upload plugin does not fit really).. I'm fine with it after all..23:29
blueyedbeuno: yes, 0.1.0~bzr44-123:29
beunooh, very cool!23:29
beunoI didn't know23:30
jamlifeless: it seems when you landed the btree format repository into bzr.dev, we lost the "convert indexes in place" code.23:40
jamwhich is a bit of a shame, as it makes it more difficult to set up a test repository23:40
jamdoes the code in the plugin still work?23:41
=== Ng_ is now known as Ng
lifelessjam: the plugin code needs some adjustments, to use bzr's index logic etc23:56
lifelessjam: the reason I didn't port that code across is that for gc its not helpful; and I don't plan on suggesting that dev2 become a production format ever23:57
jamlifeless: sure, it just makes my life easier when trying to test stuff out :)23:57
jamI'm hacking around it now with a script23:57
lifelessback shortly, fooding23:59

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