mkanatpoolie: http://twitter.com/mkanat/status/852048474200:20
lifelessmkanat: thanks, I've reweeted :P00:21
mkanatlifeless: Yay. :-)00:21
mathrickoh nice00:22
mathrickhow big is the repo?00:22
mkanatmathrick: Oh, um, about 7000 revisions on trunk.00:23
mathrickaha, that's pretty modest00:23
mkanatYeah, not enormous.00:23
lifelessits not how big it is :P00:25
bjpbzr support https?01:54
KilrooCan you be more specific?01:58
bjpi was trying to find a bug report i saw earlier02:01
bjpit was throwing an error because I am using a self-signed certificate for an internal https server02:01
bjpthat one02:04
ubottuUbuntu bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Triaged]02:04
bjpit's marked as fixed released a long time ago02:04
bjpoh it was changed02:05
dcolesI was wondering if anyone could offer some advice for storing file modification times along with file contents in bazaar.02:16
lifelessdcoles: perhaps some context on why?02:16
lifelessif it is for e.g. make, then 2.1 will do better for you02:17
dcolesSure. I'm trying to use bazaar as a way to track modifications on a website using wget --mirror. I'm mainly interested in the Last-Modified header which gets stored in the mtime of the file.02:18
lifelessAfC: you pung02:18
lifelessdcoles: so, the closest you could get would be to script bzr via the python api to do one commit per timestamp you see, of only the modified fiels with that timestamp (using a fuzz factor to group changes)02:19
lifelessAfC: sms me.02:20
lifeless-> food02:20
AfClifeless: I think I was looking to see if you were coming into Sydney for Beer last Friday. I've subsequently gathered you're out of town02:20
dcolesHmm... I guess that's one option. Would I be able to add it as metadata to the file, say, just before commiting the changes?02:20
KilrooI never metadata I didn't like.02:29
dcolesKilroo: Something similar to `svn propset` would likely suit my purposes, but I don't think I've seen a way to access it via the bzr command.02:30
dcolesMight just be easier to generate a 'last-modified' file and track the changes in that instead.02:31
KilrooIf you don't want it any more granular than that, couldn't you just look at when you committed?02:32
dcolesWell I really wanted to know the server side 'last-modified' of the html files rather than when I mirrored the file. If it turns out to be too hard I guess I'll just run the mirror script each day and have to be satisified with just a 'day' resolution.02:36
KilrooWhat I meant was, if you only get as specific as when that one file was last modified, then you're only going to get one modified time per commit. If you aren't committing shortly after making changes I suppose it could be significant to know when that one file was changed instead of when you committed, but I didn't think of that at first.02:39
dcolesOh. I see what you mean.02:41
james_w('need at least bzr 2.1.0rc2 (you use %r)', (2, 2, 0, 'dev', 1))02:42
james_wthat seems wrong to me?02:42
dcolesKilroo: wget with --mirror sets the file timestamps to what ever the server says for 'last modified', so there could potentially be a few different modification times02:42
KilrooBut not for the one file you were going by.02:43
KilrooOr did you mean make a file and record the last-modified times for everything else IN it as text?02:43
KilrooGotcha. That makes me wonder two things.02:43
dcoles`ls -l` or something a little less hackity02:44
KilrooFirst, does wget output the last modified times as it processes the files.02:44
Kilroo...and that was my second suggestion.02:44
KilrooHeh. I actually have been working on setting up something at work to let me use a combination of rsync and bzr to pretend that the stuff we still have on plain ftp is version controlled. Modified times hadn't even occurred to me.02:45
KilrooThe experience has, however, convinced me that all our log files should be kept above the web document root to make version control easier, instead of just for all the other reasons I'd already had.02:47
dcolesKilroo: Alas no. I'd pondered just dumping stdout, but it only mentions if a file is 'newer' or 'not modified'02:48
dcolesIt'd be really easy if it was on a local machine, but it's a small external website we need to keep tabs on.02:50
dcolesWhile the original intent was for me to check by hand, sounds like a great thing to have automated.02:52
dcolesAnyway. Thanks for the advice. Given me a few more ideas to play with. :)02:53
KilrooI'd probably go with putting the modtimes into a text file after every sync and versioning that, if you can't find a convenient way to set custom metadata in bzr. And submit a ticket suggesting that the ability to track that be added, although I think typically in a version controlled environment most people are going to care more about the commits.02:54
RyNy_what's the best practice for registering a project with Launchpad? I have a Drupal site that I want to user vc with but it is large ~2gb.05:18
lifelessRyNy_: what do you mean by 'best practice'06:15
RyNy_I think I figured it out. I was wondering how much of the drupal install I should I send to LaunchPad. I suppose only the files that I change.06:16
lifelesswell if you are making a branch of drupal, surely you'd upload it to the drual namespace :)06:17
mathrickwhy does the beta PPA have any versions newer than 2.0.1?06:19
RyNy_no, my changes have to do with personal configuration changes: new modules, or server configurations06:39
RyNy_does anyone have workflow tips for managing a LAMP server with bazaar07:02
RyNy_Do I create a branch for the whole server?07:03
bob2what are you planning to put in bzr?07:04
RyNy_I've never used a vc before. I like the idea but am wondering how much of the server should go in vc07:04
bob2depends what you're doing07:05
RyNy_Do I initialize the whole server?07:06
bob2you don't put / in bzr07:07
RyNy_just what I'm working on?07:08
bob2the source code for your app might be in version control, and etckeeper is great for /etc07:08
bob2er, the source code for your app should always be in version control, but you might not deploy to servers using version control07:08
RyNy_I'm changing some of the config files in LAMP and then my cms07:09
bob2"LAMP"'s pretty vague07:09
bob2but putting the config files under version control (if they're not in /etc already) is a good idea07:10
vilahi all07:29
vilamathrick: lack of man power or automation, take your pick :-/07:30
mathrickvila: well, possibly, but it goes directly against what the links from the Download page tell you (it explicitly lists 2.1.0bX)07:31
vilamathrick: I'm pretty sure there is a thread about re-thinking the whole experience there on the mailing list07:33
vilamathrick: '[rfc] focus on Ubuntu updates rather than PPA packaging'07:34
vilamathrick: the underlying problem is about being able to put a working set of bzr + plugins there without running into broken PPAs where one plugin breaks with a new bzr version07:35
vilamathrick: your input and use case could only help the debate, so please reply there07:35
mathrickvila: unfortunately that's not possible today and I don't know if I'll manage to squeeze it into the upcoming days :\07:36
vilamathrick: then rest assure that the problem is known07:37
mathrickmhm, thanks07:39
vilamathrick: just for the record, are you using the beta PPA ?07:41
mathrickvila: I have it added to sources, but that doesn't do much, because the Karmic debs are newer07:43
vilamathrick: I see. But what are you interested in exactly: getting newer stable versions or something even newer ?07:44
mathrickvila: trying out 2.1.0rcs, because I wanted to see how that performs on the Emacs repo, which hits 550MB resident mem in 2.0.307:45
mathrickso yes, I want something even newer07:45
vilamathrick: hmm. But bzr.dev and building the extensions from source is not attractive to you I presume... OS ?07:46
vilaplugins ?07:46
mathrickvila: it's not because I've done it in the past, and it's a pain to keep track of things yourself. With .debs I can just push a button and go do something else07:47
vilamathrick: I know what you mean.... I have >10 setups maintained here but most of them can do with stable releases07:47
vilamathrick: so, there is little for you *today* but as we approach 2.1.0final, there should be a way07:50
mathrickyeah, that can wait07:50
vilalittle == bzr.dev07:50
mathrickanyway, thanks, I need to go do something else now07:50
vilamathrick: more precisely lp:bzr/2.107:50
vilamathrick: you're welcome, enjoy your day :D07:50
mgedminum, I can't seem to figure out how to resurrect a file removed in revision 7412:08
mgedminactually just the equivalent of 'svn up -r SOMEOLDREVNO' would suffice12:08
mgedminbzr cat -r 73 path > path kinda works12:10
maxbI'd be tempted to try merge12:11
asabilmgedmin, bzr revert -r 74 file ?12:24
mgedmintried it, got an error (path not versioned or some such)12:25
mgedminended up doing bzr cat ; bzr add12:26
mgedminso now it's kinda difficult to test "correct" solutions12:26
henningeHi, I may be missing something obvious but I cannot find documentation on bzrlib. Got a clue for me? ;-)12:28
asabilmgedmin, that's weird, it works here12:29
mgedminactually I tried bzr revert -r 74 subdir/file1 subdir/file212:30
Penghenninge: The source code is well-documented, and there's probably some starter info in the developer docs. There's also an API site somewhere, but I assume it's just generated docs.12:30
beunohenninge, http://doc.bazaar.canonical.com/bzr.dev/en/12:30
PengErr, :D *12:30
mgedminyeah, it should've worked, according to bzr help revert12:30
asabilmgedmin, both file1 and file2 are deleted ?12:30
asabilalso is subdir versionned ?12:31
mgedminrev 74 deleted a whole bunch of files, two of them by mistake12:31
mgedminthe subdir still exists and has files12:31
asabiltry to revert each on separately ?12:31
mgedminah, I just realized I could've got a sort of an equivalent of "svn up -r 73" by doing bzr branch -r 73 ...12:31
henningebeuno: Thanks. I've been there and that's all about using "bzr" from the command line. But in pyhton scripts I want to import from bzrlib. I think I'll just browse the code like Peng suggested. ;)12:32
mgedminwell, thanks anyway12:33
Penghenninge: bzrlib/builtins.py is a good place to start, since it's where commands are implemented.12:35
Penghenninge: So, if you're trying to automate a command or something, you can just steal the code. :D12:35
=== mrevell is now known as mrevellunch
quotemstrbzr is crashing with an internal error referencing "Unknown kind 'relocated'"13:01
ronnyquotemstr: what bzr revision, what are you doing13:04
quotemstrI have a branch at emacs/c++1x and I'm trying to merge from emacs/trunk.13:08
quotemstrSo with CWD in emacs/c++1x, I run 'bzr merge', and get the above error.13:08
quotemstrIt's bzr
quotemstrWhat actually happened was that I ran 'merge' once, got a bunch of conflicts, then ran 'bzr revert .'.13:09
quotemstrThen when I tried to merge again, I started getting that error.13:09
quotemstrAnd now it's just pegging the CPU meter, spinning while checking 'bzr check'.13:14
PengYeah..."bzr check" will not be fast on emacs.13:18
=== mrevellunch is now known as mrevel
=== mrevel is now known as mrevell
bialixhenninge: http://wiki.bazaar.canonical.com/Integrating_with_Bazaar14:20
bialixhenninge: http://starship.python.net/crew/mwh/bzrlibapi/14:20
=== salgado is now known as salgado-lunch
maxbThat's a useful wiki page. I think I might add a mention of enable_default_logging and ui_factory, unless anyone knows they are covered elsewhere?14:57
ovnicrafthi folks, i get peding merges how i can commit them?15:32
rubbsovnicraft: so you've done the merge, and you just want to commit?15:32
ovnicraftwhen i try to commit, tell me bzr: ERROR: Selected-file commit of merges is not supported yet:15:33
ovnicraftyet: myfile15:33
rubbsoh, you can't do a commit of just one file after a merge. just do a commit without any files listed. so like this "bzr commit -m "merged in things""15:34
ovnicraftand i get warning conflict tag: tagfromproject, is posible solve that?15:43
rubbsmmm... I'm not sure how to resolve a tag conflict.15:43
rubbsmaybe someone else here can help15:44
Pengbzr pull --overwrite probably will (along with the other, potentially more dangerous things it does).15:45
=== salgado-lunch is now known as salgado
devmodCould anyone clarify what does it mean for a repo to have or not have a working tree?16:02
PengRepos don't have or not have working trees. Branches do, though.16:02
PengWell, that is, repos never have working trees.16:02
devmodsorry branches*16:02
Pengdevmod: A working tree is, ehh, uh, when it creates copies for all of your files so you can edit them and commit and whatever/16:03
Pengdevmod: Sometimes you don't need one -- e.g. a central branch on a server16:03
devmodi guess I understand what they are, just not sure when am I supposed to have them16:04
lukswhen you need to 'work' with the branch16:04
luksas in, edit files and commit changes16:04
luksyou don't need to have a working tree when you are using the branch only as a revision storage16:05
devmodohh ok got it16:05
devmodThis is possible because Bazaar supports (and recommends) creating repositories with no working trees (--no-trees).16:06
devmodthat gave me the idea that repo have or not working trees16:07
PengThat just controls the default setting for branches created in that repo.16:07
devmodbut Peng says they never do16:07
devmodok got it16:07
PengBTW, you can create or remove a working tree with "bzr co" and "bzr remove-tree".16:07
PengThere is no command to change the repo's default, but you can touch/rm .bzr/repository/no-working-trees.16:08
devmodok thanks its clear now16:08
luksI think you can do it with bzr reconfigure, but I never know how to use that command16:09
PengI've been using bzr longer than reconfigure has existed, and I haven't learned it well. :P16:11
luksI think that's not the problem :)16:12
luksI've managed to learn new commands16:12
luksbut reconfigure is ... "special" :)16:12
=== henninge_ is now known as henninge
bjpdoes bzr use urllib for http and pycurl for https?16:29
bjpby default16:29
muffinresearchGiven that format 2a doesn't support subtrees what's the most current subtree compatible format? From "bzr help other-formats" it looks like development-subtree is the one, is that correct?17:17
MvGHi! bzr push over sftp is causing me trouble: http://dpaste.com/153770/17:19
MvGFirst push seems to have hit some kind of timeout somewhere. Now it looks as if things were in some form of inconsistent state. How can I recover from this, short of deleting and reinitializing the repo?17:19
* MvG has to go AFK for a while, but would really love to read some advice when coming back.17:20
lifelessmuffinresearch: there are not any stable subtree formats17:22
lifelessMvG: check using e.g. lftp whether the pack its trying to rename already exists in the packs directory17:23
lifelessMvG: if it does, please file a bug - we should handle this case, and if you use bzr dump-btree repo/.bzr/repository/pack-names we can check if the new pack is actually referenced or not17:24
muffinresearchlifeless: Are there likely to be in the future for nested trees?17:25
lifelessonce its finished, yes.17:26
muffinresearchlifeless: ok, so if I want to experiment I can use development-subtree assuming I use bzr.dev?17:29
lifelessjust understand we aren't making a strong commitment to whatever data you put in it at the moment ;)17:29
muffinresearchlifeless: ok np!17:31
jelmerkfogel, do you know if savannah is going to run the bzr smart server at some point?17:36
kfogeljelmer: I'm sure they will at some point.  How soon that point is is anyone's guess.  They're actively looking for a volunteer to help them maintain bazaar on Savannah.  I have expressed tentative interest, but have not committed until I understand the overhead of working with Savannah admins, which I fear might be high.17:39
kfogeljelmer: but, you know, if you've got a lot of spare time on your hands...17:39
* kfogel ducks17:39
jelmerkfogel: :-)17:40
kfogeljelmer: I'm only half kidding.  You'd be much more competent at it than I would be.  But if it's to be on Canonical time (which IMHO would be appropriate) then should obviously be discussed w/ manager.17:42
pooliehello kfogel, jelmer17:42
jelmer'evening Martin17:42
kfogelpoolie: hey :-).  You know GNU is looking for a volunteer to help maintain Bazaar on savannah?17:43
kfogelpoolie: from backscroll:17:43
kfogel<kfogel> jelmer: I'm sure they will at some point.  How soon that point is is anyone's guess.  They're actively looking for a volunteer to help them maintain bazaar on Savannah.  I have expressed tentative interest, but have not committed until I understand the overhead of working with Savannah admins, which I fear might be high.17:43
BasicOSXI've read the info at Bug#302987 and Bug#437626 and I'm still not sure what is holding up a 2.0.2 backport to hardy. I've got some time to volunteer would that help move 2.0.2 into hardy? :-)17:44
MvGlifeless: Now have an sftp connection. The 4c52ee0586adc8546ec9d26e89e64abc.pack it mentions does exist. Will now try the dump-btree...17:45
MvGlifeless: bzr: ERROR: pack-names is not an index of type <class 'bzrlib.btree_index.BTreeGraphIndex'>.17:47
=== keithhub_ is now known as keithhub
MvGlifeless: For compatibility reasons that's an 1.6 format repo. Maybe that's responsible in some way?17:47
MvGlifeless: Got the pack-names by hand, and it seems that the pack in question isn't mentioned in the index.17:52
MvGlifeless: I'd now go ahead file a bug report...17:52
lifelessMvG: please do17:53
MvGlifeless: I guess before I do I'll give current bzr.dev a go...17:54
lifelessMvG: no need, I can tel you its not fixed ;)17:56
MvGlifeless: thx. bzr.dev is giving me a hard time just now, for reasons unknown...17:56
MvG"bzr: ERROR: No module named testtools" in response to "bzr push".17:57
jelmerMvG: bzr.dev now depends on the testtools package17:57
jelmeralthough I think it shouldn't need it for "bzr push" ...17:57
jelmerlifeless: is testtools required for more than just the testsuite ?17:57
lifelessbut I bet its a buggy plugin17:57
MvGWant a bug report for that as well?17:58
lifelessthat is loading its tests on normal calls17:58
jelmerMvG: please, with a backtrace17:58
MvGbzr --no-plugins push was in fact the first I tried.17:58
lifelessMvG: try bzr push --no-plugins17:58
lifelessMvG: oh, ugh. please yes file a bug17:58
MvGas I know bzr-svn complains about a version mismatch on a regular basis when used with the non-system bzr setup.17:58
MvGHow do I get the backtrace for this?17:58
gerard_anyone who exactly knows how WorkingTree.update works?17:59
gerard_I think I fixed the double merge problem now17:59
gerard_but I don17:59
gerard_'t exactly know how it works now17:59
MvGlifeless: thx. It's at http://dpaste.com/153798/ but will go into the bug report as well, once I manage to get that far.18:00
gerard_it passes all selftests but I'm not sure that's enough18:00
jelmergerard_: how do you avoid the two merges?18:01
gerard_jelmer: I don't, just do them in an order that will prevent the commits with itself18:01
gerard_I just swapped the order the merges are performed around18:01
gerard_and stop if there are any conflicts after the first merge18:02
gerard_hmm, lets try that first sentence again18:02
lifelessgerard_: why not just stop if the first merge conflicts?18:02
jelmergerard_: So you update the working tree to the local branch first18:02
gerard_it stops when the first merge conflicts18:03
gerard_jelmer: exactly18:03
MvGWhat's the suggested way to give large numbers of people access to a smart server? Is there some setup that does so with a single system account, using ssh pubkeys to differentiate users with different permissions, the way some git servers work?18:03
gerard_now what? do I push it to launchpad and add a merge request?18:04
gerard_I guess it might be a good starting point for someone who actually knows what is going on18:04
gerard_any need for cleaning up the commit messages? I guess there may be some in dutch still18:05
gerard_lifeless: when you don't swap the order of merges around you have trouble rerunning the update command18:07
gerard_as it is not clear anymore that the branch you wanted to update from was out of date18:07
gerard_at least, that's what I guess was one of the problems I has18:07
gerard_also, it was quite illogical to first see the conflicts with the master18:08
lifelesshmm, I was sure it did local branch first18:08
lifelessanyhow, local first, then stop if conflicts sounds fine to me.18:08
gerard_anyway, I have only a faint idea of what's going on and why, but I added some tests for the double merge, and it passes those and the rest of the selftests18:08
gerard_if something is still wrong it is also a bug in the tests ;)18:09
gerard_I'll try to push to launchpad now ;)18:09
gerard_ok, it's at lp:~gerard-/bzr/update18:12
gerard_note that this is unrefined ;)18:12
gerard_not ment for actually merging in18:12
gerard_whoops, let me check it again... it failed a test18:14
MvGlifeless: first issue reported as https://bugs.launchpad.net/bzr/+bug/51617918:14
ubottuUbuntu bug 516179 in bzr "bzr push confused by existing pack file" [Undecided,New]18:14
gerard_ok, fixed18:17
gerard_lifeless: would be great if you could take a look at it18:17
gerard_and maybe explain why I sometimes need basis and sometimes the lca for the second merge...18:18
MvGlifeless: And the other is https://bugs.launchpad.net/bzr/+bug/51618318:21
ubottuUbuntu bug 516183 in bzr "sftp transport module requires testtools" [Undecided,New]18:21
mkanatmwhudson: ping. I wanted to talk a bit about removing the revision graph cache whenever you have a sec.18:29
gerard_brb, fixing a flat tire18:45
jelmergerard_: uhm, you are hacking on bazaar while driving a car??18:49
mwhudsonmkanat: hi19:00
mkanatmwhudson: Hey. :-)19:00
mkanatmwhudson: Are you around for a bit?19:00
mwhudsonmkanat: i'm just starting work, so yeah :-)19:03
mkanatmwhudson: Okay, cool.19:04
mkanatmwhudson: So I've started to look into the possibility of removing the revision graph cache. I checked out bzr-historycache, and so on.19:04
mkanatmwhudson: So, as I recall, loggerhead used to have a disk cache, but doesn't use it anymore (at least, not with serve-branches). Was there a reason we stopped using the disk cache?19:05
mwhudsonmkanat: no, it does19:05
mwhudsonit doesn't cache the revision objects themselves any more19:05
mwhudsonbecause bzr got so much faster that stopped making sense19:06
mkanatAhh, okay.19:06
mkanatmwhudson: Right, there's basically no reason for us to cache anything other than the revno -> revid mapping, right?19:06
mkanatmwhudson: Because if we have that for a whole tree, we theoretically don't even need the actual graph for most of the pages.19:07
mkanatmwhudson: Because we could just numerically sort the revnos.19:07
mwhudsonit still caches files-changed info and the revno graph to disk19:07
mkanatOh, right, files changed.19:07
mwhudson(quite possibly caching files-changed info with 2a branches isn't needed)19:08
mwhudsonmkanat: well, revno -> revid and revid -> revno19:08
mwhudsonmkanat: and a few other things, tbh19:08
mkanatAh, yeah, both ways.19:08
mwhudsonmkanat: look in history.py, the uses aren't hard to find19:09
* mkanat nods.19:09
mwhudsonmkanat: in particular i have no idea what get_merge_point_list is trying to do :-)19:10
lifelessMvG: thanks19:11
mkanatIt seems like a lot of what we want to do really should be in bzr or in some plugin.19:11
mkanatThough I can understand some cases where it's more appropriate for it to be in loggerhead.19:12
mkanatmwhudson: I wonder if some of this is a holdover from hgweb.19:13
mkanatmwhudson: BTW, have there been any more hangs with codebrowse? And is it actually still leaking memory?19:14
mwhudsonmkanat: it might well be hgweb hangover, yes19:17
mkanatmwhudson: I think what I'll do is just try to remove the revision cache and then do some profiling, and see which of the slow code paths are actually necessary..19:18
mwhudsonmkanat: seems reasonable19:18
lifelessmkanat: excellent19:19
lifelessmkanat: its been on the 'would be nice' for some time19:19
mwhudsonmkanat: it does seem the loggerhead is hanging much less now, so that's good news19:24
mkanatmwhudson: Cool. I haven't seen another hang reported in the log since the 19th.19:24
mkanatI mean, in the bug.19:24
mwhudsonnothing in the incident log either19:25
mkanatmwhudson: Cool.19:26
mkanatmwhudson: What about the memory usage? I couldn't really reproduce a leak after about 10 hours of trying, the other day.19:26
mwhudsonit's using 1.2 gigs, which is a lot i guess but not crazy19:26
mkanatHmm. That does seem like a lot, though.19:26
mkanatOn my system it only uses about 300m.19:26
mkanatI could make it grow to 1.5GB briefly (annotate a huge file) but it would shrink again.19:27
mkanatmwhudson: That's 1.2B RSS?19:27
mwhudsonmkanat: yeah, 1.5 gig VIRT19:27
mkanatI'd be interested to know if that's growing or if it's just huge on launchpad for some reason.19:28
mwhudsonmkanat: i bet your loggerhead doesn't have 200k potential branches to look at :-)19:28
mkanatmwhudson: Yeah, that's probably a lot of it.19:28
mkanatmwhudson: The most I tested with was 50 branches.19:28
mkanatOkay, I'm off to lunch.19:30
* gerard_ is back19:42
=== keithhub_ is now known as keithhub
=== salgado is now known as salgado-afk
=== radoe_ is now known as radoe
devmodPeng, coming back to my question if I had a workflow "repo - (trunk , branches - (fix2blah, fix3blah))" Would I want to have trees or not?20:35
rubbsdevmod: on your server, if you don't actaully do the work on it, wouldn't need trees.20:36
rubbswhen you branch from them to your local machine, it would auto matically create the trees for you20:36
devmodohhh i get it now.. i thought it talked about how the repo behaved in general20:36
luksit does20:37
rubbsno it doesnt20:37
devmodi mean it doesnt apply to users20:37
luksthe server repo is different from the local one20:37
rubbsright, a server repo is usually created with the "--no-trees" option20:37
rubbsbut your local branches are really copies of that repo20:38
rubbsbut with trees20:38
devmodgot it20:38
rubbsso when I branch from lp:bzr I get a working tree of bzr, but the server doesn't have a working tree. just the repo's history20:38
luks(for some workflows you might want to have non-tree branches also locally, but that's probably too confusing for now :))20:39
devmodso on this doc, http://doc.bazaar.canonical.com/bzr.2.0/downloads/pdf-en/bzr-en-tutorial-centralized.pdf, when they talk about optimization do they refer to no-trees or trees20:40
devmod"As an optimization, it is possible for related branches to combine their storage needs so20:40
devmodthat you do not need to copy around all of this history information whenever you create a new branch."20:40
devmod% bzr init-repo --trees ~20:40
luksit means that they share the same repository20:40
lukswhich means that it will be stored only once if the branches have common history20:41
devmodok which has nothing to do with trees20:41
luksas Peng said, you can very easily remove or re-create the tree20:41
lukswith bzr remove-tree and bzr checkout .20:41
luksso you don't need to worry about that too much20:42
devmodare there any advantages having a dedicated server vs using ssh?20:42
luksmost people are using bzr+ssh20:42
luksso ssh with bzr remotelly installed (as a command line app)20:42
rubbsso, it doesn't have to dedicated (in that it's the only thing running) but using bzr+ssh will cause less network round trips20:42
rubbsit's "smarter" so it will cause faster checkouts/branches20:43
devmodi see20:44
devmodi was also reading http://wiki.bazaar.canonical.com/SharedRepositoryLayouts?highlight=%28repo%29|%28shared%29#nested-style-project-branch-sub-branch20:46
devmodin which they recommended having a separated repo for each project instead of a single repo containing all projects20:46
devmodcan u elaborate on why is that?20:46
rubbswell, there is a few reasons20:47
rubbsone, is just organizational, if you have a project, having a separate dir is just easier to "conseptualize" but this is the least important reason...20:48
rubbsthe big reason is that when you create a shared repo, all the history and meta data is stored in the shared repo.20:48
rubbsthis means that if you have two different (unrelated) projects sharing a repo, you get lots of inter-mixed data in the shared repo20:49
rubbsthis makes that repo ineffiecient20:49
rubbsThe more "similar" the contents of that repo is the more efficient (space and speed) it will be20:50
rubbsso that means you can keep all your task branches and stuff in the same repo, but if you have a project for your web stuff, and you have a project for client stuff with totally different histories and directions of development, its best to keep those seperatied20:51
devmodohh i see ok makes sense20:51
rubbsbut if you have a project that as sub projects that share a lot in common, then you can keep them under the same repo (ie. Core web site and sister sites that share a lot of code)20:52
lifelessit doesn't really make a lot of difference for most things20:54
rubbsjust the more divergent your projects get under the same repo, the bigger that repo becomes.20:54
lifelesssame as two repos :P20:54
rubbsI had a problem when I commited some history of an unrelated project in a shared repo, and then tossed out that project20:55
rubbsmy repo is still that much bigger, but I can't delete it because my other (good) history is still intermixed20:55
lifelessyou could implement the gc command for us ;)20:55
lifelessgarbage collect20:56
rubbsI'm not much of a developer20:56
rubbsI mostly write the docs... although I haven't contributed too much lately20:57
* rubbs looks down in shame20:57
devmodso as the repo increase in size, the slower it will get u say?20:57
rubbswell. yes and no20:57
rubbsmost operations would be fine, especially if you still have a local copy.20:57
rubbswhen you have a local copy, a pull would only have to pull the difference rather than the whole ting20:58
rubbsthing* BAH20:58
rubbsbut things like bzr log will eventually take longer... as your repo grows. This is aproblem with all VCS's though20:58
rubbsI'm not intimately aware of everything that is affected by large repos in the performance area. But things that have to go through the whole history and meta data will take longer when there are more things to go through.21:00
lifelessrubbs: things that walk history won't be affected, only things that scan entire indices21:00
rubbsah, I stand corrected. Thank you21:01
lifelesswe get about a log200 scaling factor in our indices21:01
devmodohh ok great21:03
lifelessso you need to increase the size by about 200 times to add another IO to index lookps.21:03
devmodrandom question.. how do u pronounce bazaar ?21:05
rubbsoh, damn21:08
* mkanat is back.21:19
mkanatmwhudson: So it's at 1.2GB, and it's been up for like, weeks now? I'd say that means there's no memory leak.21:20
mwhudsonmkanat: process has been running since the 30th21:20
mkanatmwhudson: Oh.21:20
mwhudsonmkanat: certainly, i don't think it's a serious problem21:20
mwhudsonmkanat: it gets restarted every so often by logrotate21:20
lifelessit got restarted when it shat itself last week21:21
lifelesswith the race condition in bzrlib21:21
mkanatlifeless: Oh, is that what's hard-hanging it? Or was it just a crash?21:22
mwhudsonthat was a 500 on every page21:23
mkanatOh, okay.21:23
lifelessmkanat: https://launchpad.net/bugs/51409021:25
ubottuUbuntu bug 514090 in launchpad-code "KeyError in lru_cache when loggerhead is heavily loaded" [High,In progress]21:25
mkanatlifeless: Ohh, yes, I've seen that.21:25
RenatoSilvabzr commit --fixes=lp:123 --causes=lp:456, has anyone ever thought about that? :P21:42
PengHeh. Does anybody want credit for that? :D21:46
mkanatAnd if you know in advance, frequently enough to need the feature, that you're causing a regression, then maybe you should take a different tack on development.... :-D21:51
RenatoSilvamaybe ubuntu would use --causes a lot :D22:05
RAOFRenatoSilva: Even we tend not to upload things we know are broken :P22:16
Kamping_Kaiserblink. nested merge conflicts? gnarly.22:30
EdWyse_OfficeI don't suppose there's an option to limit the bandwidth usage is there? People are getting annoyed with me for filling the pipe while pulling a humongous repo.22:35
bob2you could use the 'trickle' command22:36
EdWyse_OfficeI'd never run across that one before. Thanks!22:37
EdWyse_OfficeThe last time I even cared to do this was back on dialup. :D22:38
Kamping_Kaiserhttp://paste.debian.net/58496/ can someone suggest a solution to this conflicts situation? (bzr resolve says no conflicts to rsolve, but status lists 3 files)22:46
dvheumenHi ... I think I found a bug, but to confirm I'd like an answer to the following question: Are negative revision numbers allowed?22:51
mzzI think I saw those used somewhere.22:55
mzzbut I'm hoping I was wrong.22:55
KilrooIf I'm not mistaken, in most of the commands where you can specify revision numbers, a negative number means count backward from the current revision.22:55
=== sdboyer is now known as sdboyer_
=== sdboyer_ is now known as sdboyer
dvheumenyeah, that's right, now that you mention it, I knew that specific use case. I'm now talking about negative revision numbers in the log :P22:56
mwhudsondvheumen: if that happens, reconcile will fix it22:57
mwhudson(we don't know why the branch sometimes gets into this state)22:57
KilrooThat I don't know about. I've been studying dvcs a lot but have had so little chance to use it that I haven't looked at a log yet.22:57
dvheumenmwhudson, Is there some sort of a bug report about that? because the funny thing is ... I only get negative numbers if I don't expand the merge revisions with -n022:57
mwhudsondvheumen: i don't know22:58
mwhudsondvheumen: yeah, that bit's expected22:58
mwhudsonfor boring reasons that users shouldn't have to care about22:58
dvheumenyou said it's something with reconcile, I'll search for that22:58
mwhudsondvheumen: reconcile will fix the branch22:58
dvheumentnx, didn't know that command :)22:58
idnaryou used to be able to cause a negative revision number by committing a merge as the first revision in a branch; but I think that doesn't happen anymore22:58
mwhudson(it's a very simple corruption of the branch metadata)22:58
mzzI vaguely recall bzr-builddeb's import-dsc using them.22:58
* mzz wanders off to check22:59
dvheumenidnar, that's exactly what happened with 2.0.422:59
mwhudsonidnar: ah yes, that rings a bell22:59
KilrooI should study the How Stuff Works more than I have22:59
idnarI had a branch like that on Launchpad once upon a time, and nothing worked right :P22:59
idnardvheumen: I guess it's not fixed, then22:59
mzzhmm, I don't see it now.22:59
dvheumenidnar, apparently :P I'm trying to find the corresponding bug report now23:00
KilrooI had this kinda screwy idea the other day.23:01
KilrooIt occurred to me to wonder whether one could write a bzr plugin that would store a content hash similar (but not really exactly analogous) to a git revision ID as metadata, and whether there would be any advantages to doing it.23:03
KilrooThe answers I came up with for myself at the time were "maybe" and "probably not" respectively.23:04
dvheumenKilroo, sounds like some real deep thought :P23:05
KilrooYeah, well, it was 2am and I was falling asleep.23:07
dvheumenokay, there is a bug report on this issue, I've subscribed to it, so this makes it this tiny little bit more important :)23:08
dvheumenKilroo, well, aren't all the best ideas late at night?23:09
KilrooSometimes. Unfortunately it's often difficult to think about them then.'23:09
KilrooAt least for me.23:09
dvheumenI'm trying to think of an advantage for your idea ... I haven't found one ... but then again, I'm not at all familiar with git, I just know the basic ideas.23:10
EdWyse_OfficeIt might be nice for lp or redmine so they could show the whole tree on a --no-trees repo23:11
KilrooWell, I don't -think- it would help with tracking code moving from one file to another, but I thought it might theoretically be possible to get some of the advantages of some of git's operations that are fast because all they have to do is compare hashes.23:13
KilrooI couldn't think of anything that seemed like a convenient way to get that benefit though.23:13
KilrooI do think I've determined that the reason bzr can't branch from two of our subversion repos at work has to do with a single file, not the entire revision, though23:17
Kilroohaven't determined which file, but I kinda got a clue when I couldn't put my local mirror of one of the servers that's still just on ftp into bzr because of a 16GB log file.23:18
KilrooThen I spent a few minutes being afraid of the 16GB log file.23:19

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