jmlpoolie: hi00:16
pooliejml, hi00:21
jmlpoolie: I was thinking about branches last night.00:22
jmlOdd_Bloke: g'day00:22
pooliejml, btw i'm on leave today00:22
jmlpoolie: oh.00:22
pooliei will be around a bit00:22
jmlpoolie: in that case I'll talk to you about branches tomorrow :)00:22
pooliei am going to check on my stacking merge for a bit though00:22
pooliethere are still some test failures in the top of robert's loom00:23
* jml nods sagely00:23
poolieunless he somehow fixed them00:23
pooliei wish it was done00:23
Odd_Blokejml: Hey. :)  How's it going?00:25
jmlOdd_Bloke: well, actually.00:25
jmlOdd_Bloke: I'm experimenting to see if rememberthemilk is better than emacs for my nefarious purposes.00:26
=== edcrypt is now known as edcrypt_
Odd_Blokepoolie: When you're next free, I'd like to have a chat. :)01:26
poolieOdd_Bloke: how about this time tomorrow?01:27
Odd_Blokepoolie: Sure, that should be fine.01:28
trowith bzr-loom, is it possible to merge the changes in the upper thread down? when i use combine-thread it just tosses my changes02:03
spivtro: you could do "bzr merge -rthread:THREAD-NAME"02:03
troi'll try that. what does bzr record do?02:04
spivIt saves the state of the loom (i.e. the current threads and what revisions they are at).02:05
trowhen would i use it? after commits? or only when i move from one thread to another?02:05
trobzr merge -rthread:initial02:05
trobzr: ERROR: No location specified or remembered02:05
spivJust before pushing, basically.02:05
troah ok02:06
trothe same error occurs when i do just "bzr merge -r thread:"02:07
spiv"bzr merge -rthread:initial ."02:07
spivMerge needs a location, not just a revisionspec.02:07
spivI just tested, and that does work.02:08
troindeed. thanks02:08
troloom comes in useful, when working with source inside an environment, which is tedious to set up02:09
spivThe idea with record is that eventually it'll facilitate merging looms; i.e. if someone branches off your loom, and makes changes including adding/combining threads, you'll be able to merge their loom state back into yours nicely.02:09
troo neat02:09
spivI don't think that's fully ready yet, but looms are already very useful :)02:09
trois there a reason why creating a new thread and then merging it back into the original results in the revision number having not one but two more decimal points?02:10
troie. rev 1 -> rev 2 -> rev 2.1.1 > rev 302:11
tro2 is the branch point02:11
spivtro: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#understanding-revision-numbers02:11
trook thanks02:11
spivIt's not specific to looms, that's how bzr revision numbering works in general.02:12
ozzloyplease help http://pastebin.org/49528 what am i doing wrong?02:48
RAOFozzloy: You're merging from the wrong directory.02:50
ozzloyso i am02:50
RAOFbzr push sftp://ozzloy@ozzloy.lifeafterking.org/~/public_html/avk/itms ... Merging from remembered location sftp://ozzloy@ozzloy.lifeafterking.org/~/public_html/itms/02:50
spivozzloy: as RAOF says, there's a missing "avk/" in the remembered location.  Do "bzr merge --remember sftp://ozzloy.lifeafterking.org/~/public_html/avk/itms"02:51
ozzloythat was a tad slow, but yay!02:53
ozzloysomething to work on tomorrow.  thank you!02:53
=== Linnk is now known as Tank|Away
hypatia_Probably tedious licencing question: does Bazaar really regard its logo as GPL? There have been uploads to Wikimedia on that basis: http://commons.wikimedia.org/wiki/Image:Bzr.jpg http://commons.wikimedia.org/wiki/Image:Bzr_icon_64.png03:17
hypatia_The logo files no longer seem to be in the source tarballs and the bazaar-vcs.org website seems to be all rights reserved.03:18
Odd_Blokehypatia: Why do you ask?03:22
=== FBI is now known as Suiseiseki
=== Suiseiseki is now known as Suigintou
hypatiaOdd_Bloke: A couple of reasons, all related to Wikimedia Commons. If those files aren't Free, they can't be on Commons, that's one reason. The other is that if the logo is GPLed, Commons should use the SVG version.03:24
hypatiaThe current justification for them being on Commons is that, apparently, as of the beginning of 2008 they were included in the tarball of Bazaar itself, which has a LICENCE file saying it's GPL. The logo files are no longer in the repo that I can see.03:26
hypatiaIf they ever were, I have not searched the history yet.03:26
spivhypatia: FWIW, I don't see a logo in the bzr-1.1 tarball, which was released mid-Jan 2008.03:29
jelmerhmm, would be nice to have some clarification about that03:29
hypatiaspiv: I am currently running bzr log on your laptop, so we'll see.03:29
jelmerbzr-gtk still ships them03:29
spivUnfortunately poolie isn't around today.03:30
Odd_BlokeIf they aren't free, they should be.03:30
spivOdd_Bloke: yeah03:30
hypatiaThey are not in Ubuntu's .deb of bzr.03:30
Odd_BlokeElse Debian'll have to package bzr as IceMarket.03:30
jelmerany nested tree gurus around?03:31
spivOdd_Bloke: heh03:31
jelmerThe serializer appears to forbid reference_revision to be None, but other parts of the code seem to assume that's a valid value03:31
jelmerLarstiQ_: pingz0rz?03:31
Odd_BlokeIs packages.ubuntu.com being unresponsive for anyone else?03:38
Odd_BlokeOK, I just found an Ubuntu mirror and looked at the diff.gz, which saved time. :p03:41
Verterokhi lifeless05:06
hypatiaLooks like the bzr repo has never contained the logo.05:21
chandlerchow can you do a non-destructive revert after adding a file you don't want versioned?05:25
spivbzr rm --keep FILE05:26
chandlerc--keep might be a nice flag for bzr revert05:27
chandlercbut thanks, that worked like a charm05:27
spivAlthough bzr rm will not delete the file if bzr thinks there might be uncommitted changes to it.05:27
mwhudsonhi lifeless05:28
chandlercwill bzr revert?05:28
chandlercthat would be unfortunate default behavior, but it was what the help indicated would happen05:28
spivbzr revert won't delete an uncommitted file either (You can test for yourself with "bzr init foo; cd foo; echo hello > hello.txt; bzr add; bzr revert")05:29
chandlercthe basic "bzr help revert" didn't indicate that behavior clearly to me05:30
chandlercbut good to know! =] that's what i wanted it to do, and I had done it once, and the output seemed to indicate it was deleting files, so I was concerned05:30
spivThe help text talks a bit about how it will make a backup of the file "if appropriate", which sort of hints that it's careful not to destroy your work.05:31
spivBut yeah, it could be clearer.05:31
chandlercyea, i read the creating a backup to mean it *would* destructively modify the file, which is why it needed a backup05:32
chandlercand in this case, i added a *very* large directory, so going through and renaming stuff would have been... messy... ;]05:33
lifelessspiv: ping05:37
spivlifeless: pong05:37
lifelessyou're about to get mail ;)05:37
ozzloyspiv: RAOF:  thanks, btw05:41
lifelessspiv: its queued05:41
Odd_Blokeabentley: Am I right in thinking that you had some work on merge directive support in PQM somewhere?05:41
spivozzloy: not a problem05:41
lifelessspiv: mail should have reached you:)05:51
Odd_BlokeIf someone could add me to the list of people allowed to post to bazaar-commits, it'd be appreciated.06:13
=== arjenAU2 is now known as arjenAU
lifelesspoolie: ping07:34
=== doko__ is now known as doko
chandlercwhat provides bzrlib.knit.* stuff?08:40
lifelesschandlerc: how do you mean 'provides' ?08:40
chandlerci'm getting an ImportError08:40
chandlerci have bzr 1.6b2 installed.. wondering if i need some additional libraries08:41
lifelesschandlerc: you probably have a 1.6b3 version of some plugin08:41
chandlercannoying... trying to follow a release branch of bzr-svn, but don't really want to be quite so bleeding edge with bzr itself08:42
chandlerchighly annoying as the released version doesn't work with 1.6b2 and contains a couple of bugs fixed in the release branch08:45
ToyKeeperThat reminds me...  I've been meaning to fix my dual bzr/bzr.dev install setup so it doesn't try to use the wrong version of plugins.08:51
ToyKeeperIIRC there was an article on an easy way to do that, if I can find it.  :)08:52
lifelessjelmer: ^ see chandlerc's comment :P08:54
lifelessToyKeeper: basically, don't use ~/.bazar/pluings for ones that hace trouble, instad link them to bzrlib/plugins/ in the version you want them for08:54
lifelessToyKeeper: our export a bZR_PLUGINS_PATH08:54
LarstiQ_jelmer: pongzorz08:58
lifelessOdd_Bloke: ping09:06
lifelesspoolie: piong09:06
Odd_Blokelifeless: Pong.09:09
Odd_Blokepoolie is on leave today, so probably isn't around.09:10
beunomwhudson, check out bug #23791409:15
ubottuLaunchpad bug 237914 in loggerhead "please provide downloadable and applicable diffs" [Medium,Confirmed] https://launchpad.net/bugs/23791409:15
AfCOdd_Bloke: how'd you go with that PHP snippet?09:18
Odd_BlokeAfC: I looked at it, thought "I'll do this later" and haven't got around to doing it yet. :p09:19
lifelessOdd_Bloke: your review requests titled 'The Diff' are context-free. I'm told if you don't set a title a sensible one is chosen09:20
AfCOdd_Bloke: most of it is actually about creating a listing of repositories, branches, and/or empty directories as you'd expect in a normal server generated index page. The "There's a branch here" part was pretty easy".09:20
Odd_Blokelifeless: I've been adding "The diff" via "Add a comment/review" just before using the "Request a review" button.  I'll use the "Request a review" whiteboard for the diff in future.09:23
Odd_Blokelifeless: Apologies.09:23
lifelessOdd_Bloke: the problem is the tmail topic09:23
lifelessOdd_Bloke: thumper says not to use the whiteboard09:23
lifelessthumper says you are setting a subject; don't do that.09:24
lifelessits a bug that there isa  field there IMO09:24
Odd_BlokeI took my prompting for adding the diff from https://code.launchpad.net/~thumper/pqm/test-bzr-home/+merge/29609:25
Odd_BlokeBut in future I'll leave the subject empty.09:25
AfCOdd_Bloke: oh, I just realized that without the Apache config the .php I sent you is probably totally lacking in context. So, http://rafb.net/p/WihwmF64.html09:30
lifelessOdd_Bloke: thumper agrees that it is all his fault, and he sucks09:31
abentleyOdd_Bloke: Here's my last work: http://code.aaronbentley.com/bzr/pqm09:42
ChristopheTHi!  What is considered to be a good web interface for bzr repositories?  I found "bzrweb" (http://mccormick.cx/dev/bzrweb/index.py/repositories) and webserve (https://launchpad.net/bzr-webserve).10:14
beunoChristopheT, Loggerhead is probably the most complete one10:15
bob2or launchpad itself!10:15
james_whey beuno10:16
beunomorning james_w10:17
james_ware you in the office?10:17
beunojames_w, yeap, got here a while ago10:18
beunoare you here too?10:18
james_wyeah, I'm hiding away in the back corner.10:19
beunoah, you sneaked in!  I got here 9am-ish, and I'm right by the door10:19
Odd_Blokelifeless: Hurrah!10:28
Odd_Blokeabentley: Thanks. :)10:28
lifelessOdd_Bloke: ?10:35
Odd_Bloke08:31:19 < lifeless> Odd_Bloke: thumper agrees that it is all his fault, and he sucks10:35
=== Tank|Away is now known as Linnk
mtaylorhey all - quick question... given a revision id, is there a _sensilble_ way to find out the tags applied to the tree _after_ that revision?10:40
lifelessjelmer: ping10:40
mtaylorlike, if we tag releases and want to be able to determine if a particular patch went in to a particular release...10:42
lifelessmthaddon: log can show tags I believe10:42
lifelessmeh mtaylor I mean10:42
mtaylorlifeless: yes... it can10:43
mtaylorlifeless: but that makes the process ... bzr log | less ... find commit, scroll back in output looking for tags...10:43
lifelessmtaylor: I suggest you fle a bug wishlist wise :)10:44
james_wmtaylor: would 'bzr log -rrevid:foo.. | grep "tags: " | cut -d" " -f2' be considered sensible?10:44
james_wmtaylor: but I agree that it would be a good thing to have10:45
james_whi lifeless10:45
mtaylorjames_w: well, I've just come across another snag...10:59
mtaylorjames_w: if I later merge from a different tree (in this case, say I'm in the 6.2 release branch and I occasionally merge up changes from the 6.1 branch)11:00
mtaylorthen I see those 6.1 tags in my bzr log output in the 6.2 ... which would lead me to believe that the fix is "in" 6.1.1111:00
mtaylorthis is silly11:00
james_wmtaylor: true11:01
james_ware you mainly interested in a single tag when you do this, or are you looking for all tags?11:02
james_wdoing it for one tag (or a list of them) is easy enough.11:03
mtaylorI think if I could pass a revspec to bzr tags, this would be cake11:03
mtaylorbzr tags -r2512.78.7..11:04
james_wasking "what tags is this revision an ancestor of?" is probably straightforward as well, I'm not familiar enough with the branch.tags interface though.11:04
james_wI'm not sure about adding that to tags, as it would seem to be to be "list all tags that are in this revision range", not "list all tags that have the start of this range as an ancestor", which means I would expect it to return the same as the grep expression.11:05
james_wmtaylor: http://pastebin.com/f3b0c221d11:29
james_wtry putting that as ~/.bazaar/plugins/which_tags.py and then run "bzr which-tags -rrevid:foo"11:30
traduffehello, is there any example of post_change_branch_tip for doing anything on the repository server when a new commit arrives through a push?11:31
traduffeit works when i commit locally, but when i push nothing happens. i have also tried using bzr serve to no avail11:32
traduffe(commit locally on the server that is)11:32
mtaylorjames_w: awesome... trying now11:34
traduffeperhaps it is related to the message "This transport does not update the working tree of" - i get that with both bzr+ssh://, sftp:// and bzr:// (what transport am i supposed to use?)11:34
mtaylortraduffe: your repository on the server should probably be created with --no-trees11:35
james_wtraduffe: remote transports won't do that for you.11:36
james_wtraduffe: your hook doesn't do what you want, or it isn't exectued at all?11:36
traduffejames_w: it is not executed at all11:37
james_wmtaylor: I still think a wishlist bug would be valuable, as I think this should be done right, and done in the core.11:37
mtaylorjames_w: cool. I'll file one if I get a chance today11:38
james_wtraduffe: I'm not familiar with hooks, so I'm not sure what to look at, sorry.11:38
james_wtraduffe: what version are you using?11:38
james_wtraduffe: server and client?11:38
james_wmtaylor: great, thanks11:38
traduffejames_w: version 1.511:39
traduffeat both sides (from the ppa launchpad repo)11:39
james_wtraduffe: I don't know what to say, sorry. Hopefully someone with a clue will pipe up.11:41
lifelessJc2k: ping11:55
Jc2klifeless: pong12:03
lifelessJc2k: wondering if we can et your procmail recipe12:18
Jc2keh, its not procmail12:18
lifelessor whatever it is :)12:19
Jc2kwget http://bzr-mirror.gnome.org:8080/vcs-mirror/trunk/download/6/mirror.py-20080624200612-su5368kmi8ua94bd-5/mirror.py?file_id=mirror.py-20080624200612-su5368kmi8ua94bd-512:19
* Jc2k blinks at the url :)12:20
Jc2ksee the actions/ folder for how the {svn,bzr,git} mirrors are created/updated12:21
lifelessJc2k: thanks!12:22
lifelessJc2k: we're looking at making an in-conference mirror12:23
lifelessJc2k: what do you think?12:23
pygilifeless, ping12:23
mwhudson(at the url, it's too late to be clicking things)12:23
lifelesspygi: hi12:23
pygilifeless, tell gnome people to stop being ignorant, and mentioning gitorious only in git context12:23
lifelesspygi: right, clearly its portable to bzr :)12:24
pygilifeless, also tell them that if needed, gitorious can fully support bzr in a two-weeks timeframe12:24
pygiand it will, as I mentioned in my blog post, through rvcs12:24
pygisomebody just gotta get me the reason to do it12:24
pygilifeless, what me and Jc2k mentioned is far more important ... coming up with the plan on how to do all things needed for the migration12:25
lifelesspygi: well, I'm doing the things12:25
Jc2klifeless: an onsite mirror? if we can get the bandwidth for an initial pull12:25
Jc2konsite branching, with bzr-avahi12:25
Jc2kshit the bed.12:25
lifelessJc2k: shipping a firewire drive from london12:25
lifelessJc2k: just need a machine to plug the thing into12:26
Jc2klifeless: i'm bouncing up and down like a giddy goat12:26
lifelessJc2k: ok, cool12:26
pygilifeless, anyway, just wanted to mention that =)12:26
pygiif they have any problems, direct them to me xD12:26
lifelesspygi: thanks! will do12:26
* pygi goes back to hacking...12:27
beunojames_w, let me know when you're hungry  :)12:32
lifelessbeuno: are you still in england?12:32
beunolifeless, yeah, I got sidetracked into working on other stuff  :)12:33
beunoso I'm here til saturday12:33
lifelessI arive sunday12:34
beunoyeah, all the fun starts when I leave12:34
beunothat *always* happens  :p12:34
james_wbeuno: I was just thinking the same thing. What is there to do for food around here?12:34
beunojames_w, there's pizza express, the cafe that's mostly for takeaways, or other pubs that I'm always unable to find12:35
beunolifeless, how's Guadec?12:35
=== acuster is now known as avc_afk
lifelessgood; intense12:35
beunoare you giving any bzr talks?12:35
lifelessyes, in 40 minutes12:42
beunolifeless, good luck12:47
beunoI'm off to lunch!12:47
lifelessJc2k: hi12:50
lifelessJc2k: you moved a module to svn recently, for use with i10n right ?12:50
Jc2kdid i?12:52
* Jc2k blinks12:52
lifelessor maybe it was someone else..12:52
lifelessJc2k: it was gnome-specimen13:08
lifelessuws: ping13:09
lifeless^ - so , danilo is looking at making this work straight out of i10n13:11
=== avc_afk is now known as acuster
svenhi! i get a traceback when running 'bzr annotate file.OTHER' while merging, if file is removed locally and modified in the other branch13:42
sveni can reproduce it with this: http://pastebin.com/m3837d47e13:42
svenusing bzr 1.513:43
svenand also 1.6b313:44
_panebi created a branch locally, added some code, and pushed it to a remote repository. when i ssh into the remote machine, the remote branch has no working tree - is this normal?13:47
lifelesssven: please file a bug13:47
svenlifeless, ok13:47
lifeless_paneb: yes,  totally normaly - other people can branch from this13:48
_panebok now i have my local mirror of the remote (trunk). i want to create a new branch for a new feature. i do bzr branch trunk feature-X locally against my mirror branch. when i do bzr log in feature-X, the branch nick is still 'trunk'13:57
jelmeryes, because the commits were created in that branch13:58
bob2the nick affects future commits13:58
bob2'bzr nick' will show you what it will be recorded as13:58
_panebok, thanks13:59
MvGI just wondered, is there a way to have a single working tree switch between different branches?13:59
LarstiQ_MvG: bzr switch13:59
MvGUse case: large compiled project and I'm working on multiple features.13:59
bob2yes, with the 'bzr switch' command13:59
LarstiQ_MvG: which is useful in exactly that usecase, yes :)13:59
* MvG is reading switch help13:59
MvGAh, so I create a lightweight checkot initially, and then use switch to change the branch. Nice. Thanks!14:01
guilhembiabentley: hello! could you please post an update in support issue 2413? A colleague hit a criss-cross merge where the merge3-per-file bzr version gives seemingly bad content conflicts, as we had already observed, and which is a problem you were working on.14:05
svenlifeless, ok, i filed https://bugs.launchpad.net/bzr/+bug/24657314:06
ubottuLaunchpad bug 246573 in bzr "'bzr annotate file.OTHER' during contents conflict gives traceback" [Undecided,New]14:06
MvGjelmer: Are there any news in bzr-svn regarding fetching history explicitely for the given branch, as opposed to implicitely for each history request not contained in the cache?14:08
guilhembiabentley: the colleague is Sven who is on this channel, by the way.14:08
lifelesssven: tanks!14:09
guilhembiabentley: he used the "bzr merge --mysql" plugin to kill those conflicts,14:09
_paneband finally, how do i create a release (export) from the remote trunk, given that it has no working tree?14:09
jelmerMvG: not particularly14:09
guilhembiabentley: but this feels a bit anxious, as one cannot be sure that all of them were incorrect. So we're looking forward to the full solution.14:09
jelmerMvG, I've kept my svn-1.5 branch up to date with the 0.4 branch and started looking into the logic behind all this and then got distracted14:09
svenhi guilhembi and lifeless! yes, would be very nice to have a solution to this! the merge --mysql thing is good, but i have to go through all the content conflict files and check the result...14:11
MvGjelmer: Understandable. As long as it isn't forgotten completely, that should be all right.14:11
MvGjelmer: Especially as current 0.4 branch seems to work with svn-1.5 as well, there is not that much of a hurry.14:12
bob2_paneb: normally you'd use your local version of it, but bzr export takes a branch argument14:12
_panebbob2, ok, i'll use the local branch, but i did pass the branch to export14:13
bob2_paneb: and what happened?14:13
_panebbob2, i inverted the branch name and archive names :P14:14
LarstiQ_jelmer: you pinged me for something?14:25
jelmerLarstiQ_, yeah, nested tree support14:25
jelmerLarstiQ_, What's the status ? :-)14:25
LarstiQ_jelmer: the same as in London afaik14:25
jelmerLarstiQ_, Also, do you know whether it's possible to nest another branch14:25
jelmerwithout specifying a revision in that branch14:25
=== LarstiQ_ is now known as LarstiQ
jelmeror, to word it differently, is it possible to nest the tip of another branch rather than a specific revision14:26
LarstiQjelmer: as in, always pull the latest version?14:26
LarstiQjelmer: I don't think so14:27
jelmercrap, that makes nested trees unusable for svn:externals :-/14:27
LarstiQyou think?14:27
LarstiQjelmer: ime svn:externals are mostly pinned at a specific revision.14:27
jelmerIt is possible to pin them, but almost nobody uses the pinning14:28
LarstiQstill would like to update once in a while of course14:28
LarstiQjelmer: hmmm, our experiences conflict :)14:28
jelmerin particular because the revision an external is pinned to is annoying to update14:28
jelmeryou have to update the external14:28
LarstiQpropedit it?14:29
jelmerwell, at least that makes it easy to decide whether to wait for nested trees before I introduce that new mapping format...14:31
LarstiQok, let met dig through the code a bit.14:33
awilkinsjelmer: Hello, was that log informative at all for the bindings?14:34
jelmerawilkins, yeah, I just haven't had much time to look into them yet :-/14:40
jelmerthough some may be fixed now because of the move away from fs access14:41
=== tale is now known as tethridge
jelmerawilkins, Yeah, any chance you can run it again?14:46
jelmerthe number  of errors should've gone done quite a bit14:46
LarstiQjelmer: fs access?14:46
jelmerLarstiQ: Rather than using a working copy to create revisions for testing14:46
jelmerwe now talk directly to the database14:46
LarstiQjelmer: ok, I'm severely lacking context14:47
jelmerLarstiQ: this is in bzr-svn14:47
LarstiQjelmer: that I understood :)14:47
jelmerLarstiQ: using a working copy to build revisions is quite slow14:47
jelmer(an actual directory in the file system we modify and then commit in)14:47
jelmermainly because svn sleeps in between operations to avoid funny timestamp business14:48
jelmerinstead, we now just talk to the Subversion repository directly without using a working copy14:48
=== Christop` is now known as ChristopheT
LarstiQjelmer: an svn working copy?14:48
jelmerLarstiQ: yes14:49
jelmerBazaar doesn't have working copies, only working trees :-P14:49
awilkinsjelmer: I'll run it later, this isn't my build machine14:50
LarstiQjelmer: oh feh terminology ;P14:50
MvGjelmer: Current bzr.dev and bzr-svn 0.4 repeatedly fail to branch the inkscape repo for me: http://rafb.net/p/fvOeJD27.html14:51
MvGLooks like the server became impatient and dropped the connection, but I would expect bzr-svn to reestablish connection at least once before giving up.14:52
jelmerMvG: Reconnecting would be a job of the svn client library imho14:53
jelmerMvG: The problem is that we don't have a good way to determine why an operation fails14:53
jelmerthe same error code is returned for everything that fails when using the webdav transport14:54
MvGjelmer: We could examine the error message, serach for "connection.*closed" or some such.14:54
MvGUgly, I know.14:54
jelmerThe error message is useless since that can be localized14:54
MvGStill a dropped connection would differ from most other errors in that retrying the exactly same operation again would succeed.14:55
jelmerYeah, but that would mean adding fallback code everywhere and that seems too much for a workaround like this14:56
MvGSo how would you suggest I proceed? Try to implement reconnects, fall back to using svn without bzr, or bug the subversion lib devs trying to get reconnects and/or sensible error messages there?14:56
jelmerwell, simplest solution would just be to run the command again and let bzr-svn continue where it stopped14:56
jelmerbut in the end the subversion lib should be fixed first14:57
chandlercjelmer: any clue on using the 0.4 bzr-svn branch with bzr 1.6b2?14:57
MvGWhich I did before I wrote about "repeatedly failing" up there.14:57
jelmerchandlerc: You need a newer version of bzr than 1.6b214:57
jelmerMvG: Try the command again as a user I mean14:58
chandlercjelmer: where would i get it from? i'd rather not run bzr right off the tip of development14:59
chandlerc(if i can even do that)14:59
MvGjelmer: I already deleted the branch directory and restarted the branch command from the command line. As the shared repository was still in place I had hoped it would continue there, but it seems that wasn't enough.14:59
jelmerchandlerc: You would need bzr.dev for the 0.4 branch at the moment14:59
jelmerMvG: If the shared repo is still there, it should be continuing15:00
jelmerMvG: Does "bzr info" in the repo say those revisions are there?15:00
MvGjelmer: 0 revisions. The last message from bzr-svn was "determining changes". No status message afterwards yet, seems to be still working. Not much network traffic either.15:03
jelmerMvG: it may've saved the cache though15:04
MvGjelmer: Yes, the cache should be complete. Command just died again. Next time around I guess I'll wireshark things.15:05
Odd_BlokeWoo, I have merge-directives working in PQM.15:09
Odd_BlokeIn a 'has worked once for me' type of way, before anyone gets too excited. :p15:09
jelmerOdd_Bloke: W00t! Congrats :-)15:09
=== mw|out is now known as mw
Odd_BlokeAlmost entirely Aaron's work.15:10
chandlercjelmer: is running bzr.dev viable? ie, is it stable enough to use day to day?15:13
chandlercjelmer: i would gladly run the released bzr-svn and avoid all of this, but there are bugs fixed since then that I depend on. ;]15:14
jelmerchandlerc: yeah, I've been doing so for the last two and a half years without any problems whatsoever15:14
jelmerOdd_Bloke: Still, this is nice to finally have15:14
Odd_Blokejelmer: Yeah. :)15:15
MvGjelmer: OK, the network is busy all the time with PROPFIND requests. Not much of throughput, so it didn't show up on my network usage docklet. I got a gdb stack trace somewhere in between, and it lists ra_get_dir as the function called from python, but as the error message indicates _fetch_switch instead, I'd rather assume the issue to occur in the switching code. Can you reproduce the issue?15:21
jelmerMvG, what's the url exactly?15:23
MvGjelmer: http://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk is the branch, http://rafb.net/p/fvOeJD27.html my error command line and error message.15:24
jelmerMvG: You know about -Dtransport?15:27
MvGjelmer: In theory yes. Should I try to get a log for this?15:28
jelmerMvG: I suspect this is just the server being a pain15:29
jelmerso far everything is working smoothly here though15:29
MvGjelmer: Do you have any idea what bzr-svn is doing all the time here? It prints a progress bar about determining what revisions to fetch, that bar vanishes about halfway through, and afterwards I see nothing and the code calls those get_dir things and issues PROFIND requests for various dirs. SHouldn't all that information be available form the log?15:31
jelmerMvG: It's figuring out what revisions are present in Subversion and which ones are missing in bzr15:31
jelmerMvG, it needs to look at the file properties of a path to figure out what its revision id is15:32
MvGSo basically it's asking the server for each and every dir in the tree to tell it what files are present and what revisions IDs they have? I thought revision IDs were a bzr thing.15:33
jelmerMvG: It's only looking at the file properties of the branch itself15:34
jelmerso /trunk usually15:34
jelmerMvG: But revision ids have to be preserved when pushing revisions into Subversion15:34
MvGjelmer: My wireshark capture says otherwise.15:34
jelmerand they're stored in file ids15:34
jelmers/file ids/file properties/15:34
MvGI see. Still looks like something was going wrong here.15:35
jelmerMvG: It's doing requests for get_dir() on things other than branch paths?15:35
Odd_BlokeWas just debugging why PQM wasn't accessing remote source locations when using merge directives.  I hadn't actually created the remote branch. >.<15:35
MvGIt's difficult to match network traffic to function calls, or trace the lib calls in some sensible way, but I think so.15:36
MvGAs it was running get_dir at some arbitrary point during all those PREOFIND requests, I'd assume get_dir to be the source of at least most of those. And as I'd assume get_dir to only issue a handful of such requests, I think there is either a bug in get_dir or it's being called repeatedly.15:37
jelmerMvG: get_dir() is being called repeatedly15:37
jelmerMvG: It's probably called awfully often but hopefully only doing a single request each time15:38
MvGjelmer: I have the -Dtransport log ready. Opening RA connection to repo root, then a long break, then a list of unsupported properties immediately followed by the traceback.15:38
LarstiQisn't that worse than doing more requests less often?15:38
jelmerLarstiQ: There is no way you can get multiple results out of get_dir()15:39
MvGjelmer: Why is it called awfully and there are PROPFINDs for different dirs when you are only interested in the file properties of the branch itself? Or do you mean all files within the branch as well?15:40
jelmerMvG: It's called for each revision in which the branch path changed15:40
MvGmore requests less often would seem like less overhead.15:40
jelmerMvG: I'm pretty sure it's not called for the files inside of the branch15:40
jelmerMvG: Though they are returned by get_dir()15:40
Odd_BlokeRight, I'm done for the day.15:40
Odd_BlokeI'll send the merge directives patch in tomorrow, I want to make sure I'm not too tired when checking through it.15:41
Odd_BlokeAlso I think I'm beginning to become one with this chair.15:41
MvGjelmer: Your branch still progressing smootly? I've reproduced the problem several timjes here in that time, so if it survived up to now, it's likely to continue to its completion.15:41
jelmerMvG: yeah, it works fine here15:41
jelmerI'm actually updating an existing branch15:42
jelmerI'll try a fresh one15:42
jelmerMvG: Can you pastebin that .bzr.log file somewhere?15:42
MvGjelmer: Strange. You're on svn 1.5?15:42
jelmeryeah, Subversion 1.5 (not the svn 1.5 branch)15:42
MvGjelmer: No difference there. Which makes the different behaviour even stranger.15:43
MvGjelmer: http://rafb.net/p/H2WMRd54.html15:45
=== thekorn_ is now known as thekorn
Pieterlifeless: bzr.dev is ~25MB in git, which might be a better comparison than the NEWS file, so if the 0.4:0.6 ratio then keeps up, you're looking at ~18MB for bzr.dev15:50
lifelessPieter: yes, I did a test run with more data and got 16MB for the texts15:50
lifelesstotally untuned yet though, I think I can probably get higher and make some different tradeoffs with better compressor heuristics15:51
lifelessbeen doing talks and stuff since15:51
abentleyguilhembi: jam would be the best person for that, since he's working on the issue right now.15:52
jamlifeless: as an aside (i'm *really* trying to get the merge stuff done right now :). How long of a delta chain are you allowing, and how does that impact decompression speed15:52
lifelessjam: well, decompresion is decompress(); parse-delta; copy-bytes-from-basis15:53
lifelessjam: so the IO and decompression size emittied is really the cactor, *not* the length of the chain15:53
lifelesscurrently 60% of reconstruction is in cStringIO.readlines15:54
lifelessso I'm going to eliminate that call altogether for the basis15:54
MvGjelmer: I've managed to extract the HTTP requests from my network capture: http://rafb.net/p/Mc5IIX11.html15:55
jelmerMvG: they're not very useful without the calls that call them15:56
jamlifeless: another aside... we may want to consider a pyrex extension to split a string on '\n', since we can't use string.splitlines()15:56
lifelessjam: right; or just not do splitting :P15:57
jamsplit('\n') strips the final '\n' out, so we can't strictly use that eihre15:57
jamlifeless: well, once we rewrite the apis to allow that15:57
troi'm using bzr-loom 1.3 with bzr 1.5 on python 2.5 on windows. when i merge changes from a thread immediately above the current using merge -rthread:above it merges fine, but then when i up-thread i have to merge again for some reason.15:57
trothis results in some strange looking merge graphs in bzr vis15:57
trothe merge doesn't change any files, because i just transfered all the changes from the upper thread into the lower one, so shouldn't moving back up not change anything?15:57
lifelesstro: well, once you've merged the thread above, you don't need that thread anymore, right ?15:57
trolifeless: but i do. i have more stuff to change. the merged stuff is just the immediate changes needed by the lower thread15:58
lifelesstro: there is an open bug about this actually, its mainly UI love, to 'fast forward' the thread for you15:58
lifelesstro: oh, so you're not merging everything from the thread above?15:58
trolifeless: i'm merging everything, but i'd like to continue working on that thread after i've merged. the upper thread is potentially a big feature that i'd like to merge incrementally into the stable thread (lower) as i get work done on the upper15:59
troi guess i have to create a new thread for every such merge?15:59
lifelesstro: as a workaround yes16:00
trook, thanks. i'll search and subscribe to the bug16:00
lifelessjust merge; commit; create-thread thing; switch old-thread' bzr combine-thread16:00
trospeaking of combine-thread, i think it's a little misleading. i would expect that operation to merge my changes into the lower thread, but instead if just tosses them. it's a good thing i tried it out on a test branch first before using it for real :)16:02
tromaybe it should just be renamed to delete-thread?16:03
troi can't seem to find the bug. maybe my search-fu isn't up to launchpad's par. what should i be looking for? bzr-loom returns nothing16:03
trooh. i should be looking in the bzr-loom launchpad, of course, not bzr16:04
MvGjelmer: I'm running the command through gdb and pdb to find out more about the causes. "determining revisions to fetch" has 19219 to go, but is done after 8576. strange.16:08
jelmerMvG, new clone breaks here as well16:08
jelmerMvG: that may make sense, if the branch was created in that revision for example16:09
MvGIs there any decent way to figure out what python function invoked a given native C function? Like who called ra_get_dir? The gdb stack trace isn't much help, and my pdb breakpoints seem to have missed the invocation.16:10
MvGjelmer: Unlikely for trunk, but possible.16:10
jelmerMvG: There are gdb macros that allow you to print the python stack from within gdb16:11
jelmerMvG, another possibility is that you already had the revisions up to 857616:11
jelmerMvG, alternatively you can just add more mutters16:12
MvGI somehow doubt that the gdb macros will be much use, as most function call parameters seem to be optimized out.16:13
jelmerthey work fine here16:14
jelmerhmm, the knits files don't appear to be written to disk anymore16:14
MvGjelmer: I've got a high-priority issue here. I guess I'll be looking at the inkscape issue later on again. If you can find more about it by then, I'd of course be more than happy.16:15
jelmerMvG, k16:16
lifelessMvG: I know that ted succeeded with inkscape16:19
lifelessMvG: And that it was _slow_ due to sf.net16:19
lifelessMvG: perhaps you could branch his converted branch as starting point16:19
MvGlifeless: With current bzr-svn and bzr.dev starting from scratch? Might well be that the slowness is mostly due to sf.net, but still its annoying that bzr-svn is so much slower than svn itself. Prevents people from switching to bzr.16:20
MvGlifeless: I guess I could, but I coluld also start from my svn checkout, or from the lp mirror, as I don't intend to push any changes.16:20
lifelessMvG: we traced it - sf.net was taking many seconds per request16:21
MvGStill, I'm usually more interested in fixing issues that I encounter than in working around them.16:21
lifelessMvG: they have some scaling issues16:21
lifelessMvG: I agree; using --stacked will help somewhat, when al lthe pieces have landed16:21
jelmerMvG: a large part of slowness in bzr-svn is due to bzr itself16:24
mtaylorbzr: ERROR: bzrlib.errors.ReadingCompleted: The MediumRequest '<bzrlib.smart.medium.SmartClientStreamMediumRequest object at 0xb787a68c>' has already had finish_reading called upon it - the request has been completed and no more data may be read16:28
mtaylorthat ring any bells with anyone?16:29
=== jaypipes_mysql is now known as jaypipes
lifelessmtaylor: thats usually a second-order error16:31
lifelessmtaylor: I believe spiv has posted some stuf about debugging that16:31
jelmerMvG: Found the error16:33
jelmerfor some reason we're trying to update between 10643<->1064316:33
jelmerand the sf.net server doesn't like that :-P16:33
MvGjelmer: Will you write a fix?16:34
jelmerI'm looking into how hard it is16:34
jelmerIt appears to be caused by tricky changes16:34
jelmer   A /inkscape/trunk (von /trunk/inkscape:10642)16:34
jelmer   D /trunk/inkscape16:34
MvGSounds like one would want a test case for such tricky situations, and ensure that test fails unless the fix is in place.16:38
jelmeryeah, I always do that for regressions16:39
mtaylorlifeless: I'm getting an error from search...16:43
jelmerjam, lifeless: What's the plan for 1.6?16:44
mtaylorlifeless: http://pastebin.com/m6bd9746e16:44
jelmerMvG, Hmm, I spoke too soon16:54
jelmerMvG: it has to do a fresh checkout in that case so it's correct behaviour16:54
MvGjelmer: Requesting update for the same revision is correct behaviour?16:55
jelmerMvG: Yes, iff you specify start_empty=True16:55
jelmerthat basically means "send me all the data in this revision"16:55
jelmerjam: ping?17:27
jamjelmer: ?? If it is about 1.6, I don't really know what the plan is. I'll try to bring it up at the next standup meeting. My best guess is that we are waiting for Stack to land, and Martin is working on that ATM17:29
jelmerjam: Ah, thanks17:29
jelmerjam: The other question was about my ignore patch17:29
jamI think the functionality *belongs* as a 'tree.add_ignore'17:30
jamThat doesn't meanit has to happen now17:30
jelmerjam: You voted tweak - what tweak would you like to see exactly?17:30
jambzrlib.ignores.XXX is much better than wallowing i ncmd_ignore17:30
Odd_BlokeThat was my first thought when I glanced at the patch.17:30
jamjelmer: I would *like* to see it moved to Tree17:30
jamif you feel that is too much, than I probably would just approve17:30
jelmerjam: Ah, ok - thanks17:31
jelmerI agree MutableTree is a better place17:31
jamOdd_Bloke: then you should be participating in the code reviews more :)17:31
jelmerOdd_Bloke, Do you have voting rights yet?17:31
jamjelmer: anyone can send a 'bb:approve' even if bb doesn't track it :)17:32
Odd_Blokejelmer: Nope.17:32
jamjelmer: also, just to be sure, you should check the rules as far as adding a .bzrignore if it doesn't exist, etc. I think you did, but it was something that just popped into my head17:32
jelmerjam: There isn't anything else as far as I can tell17:32
jamAnd the tree should be write locked while all of this is happening17:32
jelmerjam: there are existing functions for parsing the ignore file but they ignore the order17:32
jelmerjam: since they use set()17:33
jamjelmer: sure, but there *is* a WT._get_ignore_list or something similar17:33
jamwhich uses ignores.XXX to do its work for it17:33
jamI'm not 100% sure why I chose a set back then, but probably to remove duplicates17:34
jelmerjam: It does make sense when using the ignores file17:34
jamjelmer: I have a favor to ask. Can you try submitting a branch for me?17:42
jamI've had this patch since 1.4, and when I try to submit it17:42
jelmerjam: Sure17:42
jamI see it show up in the PQM queue, but then it disappears without a success/failure17:42
jamI suppose I should try pinging lifeless to have him check if I'm segfaulting PQM or something weird17:43
jelmerMaybe weird interaction with redirects?17:45
jamthat branch shouldn't redirect17:45
jamit is just a plain apache share of the directory17:45
jelmerjam: It's a look branch17:46
jamah, I guess I need to get rid of that17:46
jelmerI don't have looms installed and I get:17:47
jelmerbzr: ERROR: Unknown branch format: 'Bazaar-NG Loom branch format 6\n'17:47
jelmerDoes pqm have looms?17:47
jamIt seems that locally it is not17:47
jamI'll try nuking it and re-pushing17:47
* jelmer files a bug on PQM17:47
jamok, I just resubmitted it as a normal branch17:48
jelmerjam: if you have time, any chance you can look at bug 244306 ?17:55
ubottuLaunchpad bug 244306 in bzr "push hook not executed for new branches" [Undecided,New] https://launchpad.net/bugs/24430617:56
jelmerI'm considering whether push hooks *should* be executed for new branches17:56
jamjelmer: ATM, time is not something I have much of, I would probably say that post-changed-branch-tip should probably fire, I'm not sure if 'push' should17:56
jamI suppose if you created it via "bzr push ..../new-branch"17:57
jamit would seem a bit odd if the hook didn't fire17:57
jambut would it fire for17:57
jambzr branch . .../new-branch17:57
jamjelmer: is there a specific use-case you have in mind?17:57
jelmerjam: I have a push hook that sets public_branch in ~/.bazaar/locations.conf when I push a branch17:58
jelmerIt's a bit annoying to always have to push twice to get that to work17:58
jelmerI'll just use post-changed-branch-tip for now17:59
jamjelmer: I would probably say that running "bzr push .../new-branch" should fire the trigger17:59
jamAnd not firing would thus be a bug17:59
jamjelmer: so... I agree it is a bug, I don't have any time to fix it myself :)18:01
jelmerjam: Thanks18:02
jelmerjam: I wasn't asking for a fix :-) I was unsure about how to fix this so your comments are much appreciated18:02
jelmerjam: I just realized this would also help eliminate svn-push18:17
jelmerjam: Would it make sense to add a "BzrDir.import_branch()" function ?18:18
jamjelmer: This eliminates svn-push because it allows you to tell the local branch to 'pull --overwrite' ?18:18
jamAnd I'm not sure what you are trying to do with 'import_branch'18:19
jelmerjam: At the moment cmd_push() has its own logic for creating a new branch18:19
jamnow, if this was a *pre* push hook18:19
jamthat would make sense for svn-push18:19
jelmerjam: So creating a BzrDir.import_branch() would allow the implementation of BzrDir to override the way the branch was created18:19
jamjelmer: I don't think I would call it 'import_branch'...18:20
jamAnd the logic in cmd_push is because of a dispute between lifeless and I18:20
jambasically, if the repository exists, create a branch and fetch18:20
jamif not, push works a bit differently18:20
jelmerand it would allow it to take care of running the push hook, rather than putting the logic of running the push hook in cmd_push(which would be ugly)18:20
jam(I wanted to change sprout()/clone() to always create the target branch and fetch, his argument was it creates a branch temporarily that is not the final valid value.)18:21
jam(So instead, it only does that when the target repo already exists.)18:21
jamthe idea was to support resuming in a limited way18:22
jamthough with packs it all goes away anyway18:22
jelmerso what about something like BzrDir.clone_new_branch() rather than BzrDir.import_branch() ?18:22
jam(packs have an all-or-nothing approach.)18:22
jamjelmer: I would love to have cmd_push cleaned up and split into nice helper functions18:24
jamI think what you are asking would only change the "elif br_to is None" logic18:24
jamwhich is the case when there is a BzrDir and a Repository, but no branch18:25
siretartI need to branch from an repository via http with an broken repository. However bzr fails because pycurl fails to verify it18:25
siretartis there some way to ignore this error?18:26
jamsiretart: urlib+http://18:26
jamis the workaround for now18:26
jamwell, urlib+https://18:26
siretartbzr: ERROR: Unsupported protocol for url "urlib+https://svn.aspectc.org/repos/Puma/trunk"18:27
jelmerjam: yeah, I agree18:27
jelmerjam: I'll give this some more thought, thanks for the comments18:28
jamsiretart: well there youhave to ask jelmer, since it seems to be an interactiong with svn and https18:28
siretartjelmer: does bzr-svn work at all with urlib?18:28
jelmersiretart: try svn+https://svn.aspectc.org/repos/Puma/trunk18:28
siretartaah, much better!18:29
jelmervila, ping18:30
tolstoyIs there any way to "tag" a branch remotely, or is there a super fast way to do it outside of that?18:31
jamtolstoy: 'bzr tag -d path/to/branch' ?18:32
tolstoyI want to create release branches over a lot of projects all at the same time, but need to tag the branch point.  If I didn't need to tag, I'd just bzr branch sftp://blah/head/project sftp://blah/branch/prject.18:32
tolstoyjam: I think that requires running on the same machine as the repo you're branching.18:33
tolstoy(We're using a source-of-truth model.)18:33
tolstoyIf I run on the actual server, branch will generate "working trees" which I don't want.18:34
jamtolstoy: I just tested it with bzr+ssh and it worked18:35
jamI would expect -d to be fine with sftp:// as well18:35
jamtolstoy: is the 'no-working-trees' flag set on the server?18:36
jamtouch .bzr/repository/no-working-trees18:36
jamif it isn't18:36
jamthat should prevent working trees via 'bzr branch' (bzr co still creates them)18:36
tolstoyHm. Okay. There's a LOT of projects up there. I'll see if I can get bzr+ssh working instead of sftp.18:36
jamtolstoy: it worked via sftp as well18:37
jamI don't know why it wouldn't be working for you18:37
tolstoyjam: Hm. Okay, I'll try it again.18:37
tolstoyIt might be that I did this before, then did a bzr pull, and got the "no revisions to pull" message, and just assumed the tags didn't come back.18:39
tolstoyOr a permissions issue. Oy.18:39
jamtolstoy: you can also try "bzr tags -d XXX"18:40
jamwhich shows you what tags are on the branch18:40
tolstoyYep. The command succeeded, now to double-check.18:40
jamtolstoy: and I would create the 'no-working-trees' file on the "blah" server, btw18:41
tolstoyOkay. I'll add that to my list.  It seems like a good idea.18:41
jamI'm /away for a bit18:42
tolstoyThanks for your time! I'm super happy my company is using BZR. I feel like we've leapfrogged a bunch of other companies.18:42
=== sdboyer_ is now known as sdboyer
tolstoyYep. Remote tagging is working.19:08
trohow come bzr-loom isn't listed as one of the plugins on the bzrplugins wiki page?19:09
ozzloyhttp://pastebin.org/49698 how do i getrid of this?19:19
luksozzloy: get rid of what?19:21
luksif you mean the working tree thing - http://bazaar-vcs.org/FAQ#head-927e36ce76d7ee3a9ef59baaf6aa839fc46c36aa19:22
ozzloyluks: every time i push, bzr says i need to upgrade.  when i upgrade, it tells me the branch format is already the most recent.19:22
luksozzloy: I'm afraid you can't ugprade working trees over network19:23
luksbut you probably shouldn't have the working tree on server anyway19:24
ozzloyluks: http://pastebin.org/4970019:24
ozzloythis is on the server19:24
luksozzloy: bzr --version?19:24
ozzloymaybe i need a backport19:25
luksand the format sais it needs at least 0.1519:25
luksbut 0.11 is really ancient, you should upgrade anyway :)19:25
luksor, since you don't use the working tree remotely, just remove it19:26
ozzloyluks: i use the server to share between my laptop and work computer19:27
luksozzloy: but do you share the working tree or only the branch?19:28
ozzloyluks: i'm new to distributed version control.  i'm unclear on the distinction19:28
luksozzloy: branch are the data inside .bzr, working tree are the actual files you can see19:29
lukshaving the working tree on servers is usually useless, because you don't _work_ on the server19:30
luksyou only push/pull data from the .bzr dir19:30
ozzloybut isn't that what i did?  push?19:30
luksozzloy: yes, but you have files outside of the .bzr dir you don't use19:31
ozzloyso i should just delete them?19:32
luksif you are sure you don't have any local changes on the server, I'd so `bzr remove-tree`19:32
luksbut you will need to upgrade bzr to do that19:32
ozzloyi'll have to go to #debian for that19:32
ozzloyhooray stable!19:32
luksI'm sure debian backports have recent bzr19:33
ozzloy(crusty)  thanks for the suggestion.19:33
luksas there is a lot of debian people here19:33
ozzloyand for the help19:33
ozzloyalthough it actually seems to be working fine.  i've already pushed and merged changed between the computers19:33
ozzloyi just get that message every time19:33
luksozzloy: exactly :)19:34
luksbzr will not the remote working tree, so it's outdated and then it complains19:34
lukser, will not touch19:34
ozzloywould upgrading help with the speed of the pushes and merges?19:34
ozzloybecause those are kinda slow19:35
luksyou _could_ fix it with one simple trick even without upgrading bzr, but I 'm not going to tell you that19:35
luksozzloy: that depends on your local bzr version19:35
ozzloyheh, thanks for teasing me then.19:35
luksozzloy: ideally you should upgrade bzr to 1.x and upgrade the branch19:35
luksthere was a new format introduced in 0.92 (I think) which speeds up pushes/pulls especially over sftp19:36
=== sdboyer_ is now known as sdboyer
ozzloyluks: back-ports has version 1.519:43
ozzloyand the upgrade finished19:43
Qhestionhi. how can i make bazaar add all files in the current directory/subdirectories, without ignoring any files?19:55
jamQhestion: 'find dir -print0 | xargs -0 bzr add' ?19:56
jamQhestion: if you explicitly list a file, bzr will add it regardless of the ignore list19:56
jamso you could also do "bzr add foo foo/*"19:57
jamjust depends what is easier for you19:57
Qhestionno that seems not to work19:57
Qhestiononce make finishes is will try the first version19:57
jamQhestion: the 'find'  or the 'bzr add foo/*'? Also, can you give platform, etc?19:57
Qhestion"bzr add foo/*" seems not to work19:58
jamQhestion: note that the second one doesn't recurse into subdirs of foo19:58
jamyou have to explicitly list all the files19:58
QhestionPython 2.5.dunno, Ubuntu 8.0419:58
Qhestionexplicitly listing all files is... not possible, because i have LOTS of files (it took me half an hour to compile this thingy and now i want to back it up)19:58
jamIf you are using zsh, you should also be able to do "bzr add foo/**/*"19:59
jamIf it is just .o files, you could also edit ~/.bazaar/ignore and remove the .o from your global ignore20:00
QhestionO_o this time it worked20:00
jamThough I honestly would recommend not adding compiled output.20:00
Qhestiondunno what went wrong the last time (hours ag), but "bzr add ./*" did it20:00
jamAs conflicts in .o files would be a pain20:00
Qhestionjam: its just temporary20:00
ChristopheTHi.  We are a small group of developers and push our branches (via sftp) to a directory with the sgid set (so everybody in the group can write to the repository).  However, bzr does not properly propagates the sgid on its directories.  What can we do?20:12
fullermdbzr does.  sshd doesn't.20:14
fullermdIf you use the smart server via bzr+ssh or something, it'll work.20:14
tolstoyChristopheT: What we did was make sure everyone's default group in the server was "bzr", and that our umasks were at least 002.20:17
=== Pieter is now known as GitBot
ChristopheTtolstoy: Unfortunately, this is a machine used by many other people with several projects on it...20:18
tolstoyYeah, we have a dedicated machine for the repos and all associated tasks.20:21
ChristopheTThat also means I can't install myself the bzr smart-server on it :(20:22
=== GitBot is now known as Pieter
jamChristopheT: well, I could write a simple plugin that would disable bzr trying to set the mode on files over sftp, but that would only effect people who had the plugin installed20:50
ChristopheTjam: thanks but I do not see how that will solve my problem.  The sgid bit is set on the server and not respected when .bzr is pushed.  My problem is _not_ that the sgid bit is not propagated (as https://bugs.launchpad.net/bzr/+bug/50568).20:54
ubottuLaunchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed]20:54
ChristopheTIf I create a dir from sftp, it is created with the right sgid bit.20:56
jamChristopheT: what happens is bzr does "chmod xxx" on all files after it creates them21:02
jamthis bit gets *removed* by sftp21:02
jammy plugin would basically disable the chmod21:02
jamso as long as the files get created with the right umask,21:02
jamthey will respect the sgid bit21:02
jamor, I should say, directories will still have the sgid21:03
jamand thus files underneath will have the appropriate group21:03
jamChristopheT: put another way. When you do 'bzr push' we do "mkdir XXX; chmod 2775 XXX", which gets interpreted by sftp as mkdir XXX; chmod 775 XXX21:03
jamand strips the sgid bit21:04
jamthen when we create a file underneath XXX/ , the containing dir doesn't have the sgid bit set, so the files created use the user's default group21:04
jamChristopheT: I could be wrong, but i'm pretty sure your problem *is* bug #5056821:04
ubottuLaunchpad bug 50568 in bzr "'bzr push' does not preserve sgid bit on newly created directories" [Medium,Confirmed] https://launchpad.net/bugs/5056821:05
ChristopheTjam: you are correct, I just tried and indeed chmod strips the sgid bit :(21:05
jamyep, good ol' openssh21:06
ChristopheTMaybe we should add our voice to http://marc.info/?l=openssh-unix-dev&m=117745562123264&w=421:06
jamI don't know *why*, I think it is a protection mechanism21:06
jamso you can't sgid things you shouldn't21:06
jamunfortunately, it strips it from things that you *should*21:06
ChristopheTnot propagating is a protection, not not leaving the ones that are set on the server side...21:06
ChristopheTBTW, why does bzr use chmod?21:07
jamChristopheT: to try to get around users with a bad umask set21:08
jamSort of a damned if you do, damned if you don't21:08
jamBy default creating a directory will use the user's umask21:08
jamso if they have 02221:08
jamthen directories won't be group writable21:08
jamso we chmod21:08
jambut then they lose the sgid bits21:08
jamSo *one* answer is to force users to set there umask (which they may want 022 for normal work, and only 002 for bzr work in certain directories), and not chmod.21:09
jamAn *easier* solution is to use bzr+ssh and something like bzr_access to set your umask for bzr connections21:09
jambut that doesn't seem to help *you* as you don't have appropriate admin rights on this machine21:09
ChristopheTI'll try to convince the admin to install the smart-server (but he is put off by the fact that no debian package exists)21:12
jamChristopheT: sudo apt-get install bzr21:12
jamI don't see how hard that is21:12
jambzr+ssh just requires *bzr* to exist on the server21:12
jam(and for you to have the ability to run "ssh host bzr serve --inet"21:13
jamI certainly hope that jelmer has been keeping up with the debian packaging :)21:13
pygisooooo folks, who here has time to talk with me about topics that should be included in hopeful bzr book? :)21:14
jamChristopheT: http://packages.debian.org/search?keywords=bzr21:14
* jelmer needs sponsors21:14
* jam hides :)21:14
ChristopheTFor chmod, isn't the better to try: if a created dir has >= the right permissions or has a suid or sgid bit, do not touch it; otherwise chmod?21:14
jelmerhi pygi21:14
jamChristopheT: there are a lot of possible heuristics which could be attempted, but if the g+w bit isn't set, sgid doesn't help much21:15
pygihi jelmer :)21:15
jamyou get the right group21:15
jambut the group still can't write21:15
jamI thought we had a "stat + if bits not right chmod"21:15
=== sdboyer_ is now known as sdboyer
jamChristopheT: ah, we don't do that for sftp, because of adding an extra round trip issues. We probably could, and patches for that would certainly be reviewed21:16
jamEspecially if it only effected mkdir, since we do that infrequently, versus for all file creation, which we do somewhat more often21:18
jam(ie, effecting 1 time in 1000 means you can do a bit more work each time)21:18
jam(without impacting the overall work done much)21:19
ChristopheTYes but one can then warn the user and use a default decision (either no chmod -- the sanest IMHO since if the sgid bit is set, this is for a reason, but tell tu use umaks id the bit g+w is not set -- or do chmod anyway and use an option --no-chmod to override that -- but forgetting this will screw up things).21:19
jamIf the user has the wrong umask... if chmod you  get files with the wrong group, though probably read permissions on the files (aka, you can still use it), or if you don't chmod you get no 'w' for the directory, so other people can't put new files there (aka, you can't use it at all)21:20
jamChristopheT: again, if you care deeply, I'm happy to review a patch to the sftp code. It is all contained in bzrlib/transport/sftp.py21:21
jamAnd you want to look at the "def _mkdir()" function specifically21:21
jamYou probably should also discuss it on the mailing list21:21
jamto ensure that people generally agree.21:21
jamOne man's 'just work's heuristic is often another's "it is very broken"21:21
pygilifeless, how did the bzr talk went?21:22
ChristopheTjam: if the administrator agrees to install bzr, if he does not agree then I'll try to change the mkdir logic (hopefully the bug will be fixed in sftp itself)21:35
jamChristopheT: well, it has existed for... 3+ years now, I don't know that the openssh guys are really going to change anything21:35
ChristopheTBTW, the part of the server we have access to is in a chroot environment.  Any hint about what I have to tell him to do?21:36
jamChristopheT: well, python2.5 and bzr need to be available in the chroot21:40
jambut no, I don't have a lot of personal experience with getting software working under a chroot21:41
jamI know you can run bzr from source or from your personal home directory21:41
jamas long as python etc are available21:41
ChristopheTDoes bzr creates new _directories_ after the initial push?21:46
jamChristopheT: for new-format (pack) repositories, it only creates lock directories which should be cleaned up during unlock21:47
jamolder ones used multiple levels for storage, but that is no longer the case.21:47
jamanyway, bbiab, restarting my machine21:49
ChristopheTI guess moreover that bzr does not chmod any existing directories after their creation, right?  (For the short run, then I can change the sgid by hand -- we are using righ-root-pack.)22:00
=== bac is now known as bac|away
pooliejam, hi23:11
mwhudson<insert question about branch7 landing here>23:11
pooliemwhudson: see my mail "update on stack merging"23:12
mwhudsonpoolie: ahah, thanks23:13
=== bac|away is now known as bac
jelmerpoolie: what are the plans for 1.6 ?23:15
jelmerdays, weeks, months ? :-)23:15
pooliejelmer, days, immediately the stacking branch is landed, which will be as soon as all the tests pass23:17
jelmerpoolie: Thanks!23:17
jmlgood morning Bazaar.23:18
jampoolie: hi23:26
pooliehi jam, shall we talk?23:28
jamjust a sec, talking with #bzrlp guys23:29
jamalso, I'm on linux right now, so by-phone is probably better than by-skype23:29
=== bac is now known as bac|away
pooliesure, just ping me when you're ready23:30
jampoolie: I'm probably available for a call now23:35

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