igcpoolie: I think so.00:10
igcpoolie: the hg-fast-export converter may have a few issues but I believe its working well enough for most people making the switch00:11
=== jfroy|work is now known as jfroy
=== jfroy is now known as jfroy|work
fullermdigc: Should I follow the pattern of the others and have matching API and blackbox tests for that 'not supported'?01:02
fullermd(or just one or the other)01:02
igcfullermd: whatever abentley did01:03
* igc looks01:03
fullermdMmm.  I didn't see an obvious pattern in the other tests.  I did matching pairs for the two success and two failure cases.01:04
igcfullermd: just blackbox will do I think01:05
fullermd'k.  I'll submit an update a bit later.01:09
* fullermd scampers off for a bit.01:09
=== mark1 is now known as markh
* igc lunch01:56
fullermd'k, updated patch in.02:49
=== Mario__ is now known as pygi
mi3hello, could I ask a question?04:41
spivOf course.04:42
mi3Let's say I want to separate my branch into two separate branches, because I'm splitting it into separate projects, complete with separate license restrictions.  This means that the resulting branches should contain no trace of files from the other one.04:42
mi3Let's say I create two branches from my branch, and from each one I remove the files that belong in the other one.04:43
mi3How could I remove history so files removed in each are not recoverable from that one?04:43
spivAt the moment, bzr doesn't have any way to remove some files from your branch history.04:43
spivYou could possibly use the rebase plugin or filter a fastimport dump to generate a new history without those files.04:44
mi3I also looked into bzr split, but it seems that wouldn't help me in this situation, correct?  It seemed to just reconfigure where the base of the tree is but other files' history is still in the new repository04:45
spivRight, bzr doesn't really have any facility for modifying history, basically.04:45
mi3hmmm I might have a look at the rebase tool, thanks for pointing it out to me04:46
spivYou're welcome.  I don't think it's going to be easy to do what you want, unfortunately.04:46
mi3Looks complicated.  I suppose the other option for me would be to start anew with the new project, ie don't worry about transferring across history for the files I'm pulling out under new license.04:47
* fullermd has mentally meandered from time to time around the idea of building a grammar to describe history modifications...04:48
mi3ok thansk04:48
spivYou could at least use "bzr add --file-ids-from ../original-branch"04:48
spivWhich would at least keep the filename -> file-id mappings the same, which might make attaching more history later a bit easier.04:49
mi3ah yep I see04:49
mi3So merging between them in future might be easier04:50
spivYeah.  But if you're completely stopping work on the old history and switch completely over to the new one, it's probably a pretty marginal benefit.04:51
poolie1lifeless: ping to make a 1.11 branch please05:07
lifelessspm: uncommitted changes to pqm-config on balleny.05:09
lifelesspoolie1: done05:10
spmlifeless: indeed. ta. Were they mine (implied by the spanking)?05:11
lifelessspm: well, not mine so losa05:11
spmheh. oki, will throw to the others for review and commit.05:12
spmactually - not a lot of point in review - it's been running for a month and a half....05:12
spmthanks lifeless! iz committed.05:14
lifelesspoolie1: I've shoved the lca thing in canonicaladmin05:27
poolie1maybe you should just write a simple leave/expense system as a bzr plugin? :)05:28
spmpython: import lca-expense05:29
spm... actually now I think on it. I'm sure there's an emacs key binding already for lca expenses.05:29
* spiv -> weekend...07:01
fullermdIs it just me, or is 'help revisionspec' lying?07:01
fullermd``while "bzr diff -r 3647..3649" includes the changes done in revisions 3647 and 3648, but not 3649.''07:02
fullermd(I hate the rest of that paragraph anyway, because it's perpetuating thinking of emergant properties as special cases, but...)07:02
vilahi all07:11
El_Guille2hi vila07:16
poolie1fullermd: it's correct07:37
poolie1no, you're right, it's wrong!07:37
poolie1and confusing07:37
fullermdYeah.  That part I quoted is wrong.  Other parts are at least partly wrong.  And the whole thing is a bit eye-crossing.07:38
fullermdThe closed-vs-open range distinction made me take a mental fault to page in the terminology.07:40
fullermdAnd then when you do, you realize that its use of precise terms like that is imprecise, since the diff range isn't open, it's half-open.07:41
fullermdVery confuzzling   :(07:41
poolie1it's the other way around07:49
fullermdMmph.  See what I mean?  That's a meaning of the term I didn't even have in my brain.  When I think half-open, it doesn't imply which half.07:57
fullermdAnyway.  You wanna just fix it?  It seems to trivially correct that it would be ridiculous for me to work up a patch and submit it...08:01
poolie1can you send a patch, i'm in the middle of something...08:09
poolie1specifically rolling 1.11rc108:10
fullermdDon't roll it too tight.08:13
Peng_Congrats on the release (candidate). :)08:13
=== poolie1 changed the topic of #bzr to: Bazaar version control system | http://bazaar-vcs.org | please test case-insensitivity in 1.11rc1 | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/
vilapoolie1: ping08:23
poolie1hi vila08:52
=== poolie1 is now known as poolie
=== thekorn_ is now known as thekorn
BUGabundohi guys09:31
BUGabundo$ bzr branch lp:gwibber  -Dhpss09:31
BUGabundoPermission denied (publickey).09:31
BUGabundobzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)09:31
BUGabundoHPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x27056d0>09:31
BUGabundomeans anything to anyone?09:31
fullermd--> Permission denied (publickey). <--09:33
BUGabundoI know! but what that is mean?09:34
BUGabundolaunchpad permission changed?09:34
BUGabundoor did my key expire?09:34
fullermdThat you don't have your key set up on LP (or you're trying to use a different key)09:34
BUGabundohow do I check what key am I using with brz branch?09:35
fullermdIt should just use whichever ssh will grab.09:36
BUGabundocan you help me debug it, please?09:38
lukstry: sftp -v YOUR_LP_USERNAME@bazaar.launchpad.net09:40
fullermdI don't really know how to offhand.  I've only got one private key.09:40
BUGabundois it any helpful fullermd, luks ?09:49
luksit means that neither of the keys matches https://launchpad.net/~bugabundo/+sshkeys09:50
BUGabundoI only have 1 sshkey09:50
BUGabundoits the same for years09:51
luksyou have at least two in ~/.ssh :)09:52
BUGabundolet me check just to be sure!09:53
BUGabundoyeah just one private and one public key in there09:54
luksno, two private keys09:54
luksone RSA and one DSA09:54
BUGabundoI have an RSA09:55
lukswell, does the public key you have there look like https://launchpad.net/~bugabundo/+sshkeys ?09:55
BUGabundooh wait09:56
BUGabundomessing SSH keys with GPG09:56
BUGabundoI have an expired DSA09:56
BUGabundoon my ubuntu@BUGabundo.net key09:57
BUGabundocould be it!09:57
BUGabundojust re-did the import key process and got : The key B905F0C5B1924A9BA8F77E5A6398A34BA1784EBB has already been imported.09:59
BUGabundocould a name change cause this prob luks?10:00
BUGabundomine is .ssh/id_rsa.1.pub and not .ssh/id_rsa.pub10:00
luksyou need a matching private+public key10:01
BUGabundosome how the key got renamed!!!!!!10:02
BUGabundoshould I file a bug ?10:03
luksa bug where?10:03
BUGabundomaybe gnome-keyring ( jaunty; urgency=low10:04
BUGabundogot an update today!10:04
luksheh, jaunty10:06
BUGabundoluks by the way... do you know what's up with bzr-beta at LP PPA?10:11
luksno, sorry10:12
BUGabundogetting 404 for a week10:12
BUGabundofiled here https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/31539810:20
ubottuLaunchpad bug 315398 in gnome-keyring "ssh key renamed (possibly) after upgrade" [Undecided,New]10:20
Lo-lan-doHi all10:30
Lo-lan-dobeuno: I think you might be interested in the first patch in http://bugs.debian.org/51129510:32
Lo-lan-doIt relates to #305985 in Launchpad10:32
=== james_w` is now known as james_w
=== EarthLion is now known as Ollie|
eleftheriosis there something lik Trac for bazaar other than the bzr trac plugin?11:24
eleftheriossomething that I can install on my server, not hosted elsewhere11:24
LeoNerd"Something like FOO that isn't FOO" <== you'll have to explain what FOO-likeness you want11:37
eleftheriosLeoNerd: an alternative to Trac that also works with bazaar and isn't offered only as a hosted service.12:00
LeoNerdTrac does a -lot- of things.. is it just the source browser you wanted?12:01
LeoNerdOr bug trackign / tickets / wiki / ...12:01
eleftheriosLeoNerd: bug tracking, tickets and source browser12:01
eleftherioswould be nice12:02
fdvthe new unshelve commands (not bzrtools) fails with 'bzr: ERROR: No such file: None', same as reported in https://bugs.launchpad.net/bzr/+bug/309097, does anybody know if there's any other way of looking at the "shelf" and retreiving what's there as e.g. a patch?12:11
ubottuLaunchpad bug 309097 in bzr "bzr unshelve fails with "No such file: None"" [Undecided,New]12:11
fdvright :)12:12
vilabzr shelve --list ?12:14
fdvvila: nope, not in 1.1012:15
fdvthat one's omitted12:15
vilafdv: Oh yes, you have to upgrade to 1.11 ;-)12:15
fdvvila: which, incidentally, is still not out :)12:16
asacbzr-git ... can i use that for production yet?12:16
fdvvila: and I need svn-integration12:16
asaci dont need full support. just want to track a single git branch read-only12:16
vilafdv: 1.11rc1 release this morning :) (Or a few hours ago, depending on your TZ)12:16
vilafdv: But anyway, sheve --list couldn't make it in 1.10 and that's really what you want...12:17
fdvwell, yes and no, I guess, as I want the contents of the patch-sets as well12:17
fdvactually, that's what I want12:18
fdvhm, maybe try 1.11 locally and see if it12:18
fdv...'s able to unshelve for me12:18
vilaTo see the shelf content I think you want 'bzr unshelve --dry-run <SHELF_ID>'12:19
fdvvila: yes, but that fails with the above error :p12:19
vilafdv: Oh sorry, I don't use shelve myself :-/ Looking at the code, a shelf-id seems do be of the form shelf-([1-9][0-9]*)...12:22
fdvvila: it apparently finds the correct patch set12:22
fdvas it reports the message I input12:23
fdvbut it fail :p12:23
fdvcrap, same error with 1.1112:27
fdvso the contents are presumably broken12:27
fdvvila: but thanks for the tip :)12:28
beunoLo-lan-do, thanks13:21
=== asac_ is now known as asac
Lo-lan-dobeuno: Speaking of loggerhead, how can I know whether caching is used?14:06
beunoLo-lan-do, it should create a sqlite db in /tmp14:07
Lo-lan-doI see.  Any reason not to use the cachepath config entry?14:10
beunoLo-lan-do, ah, right, if you use start-loggerhead instead of serve-branches, it does14:11
beunofor the next release, I'm planning on adding a config file for serve-branches so we can get rid of start-branches all together14:12
Lo-lan-doI use serve-branches.14:12
Lo-lan-doOh, maybe I misunderstood.14:13
beunoright, so serve-branches doesn't use the config file at all14:13
beunoit will use *a* config file(s) in the next release  :)14:13
Lo-lan-doBut yes please, do get rid of start-loggerhead :-)14:13
beunoheh, will do!14:14
Lo-lan-doDo you use a lot of features from YUI ?14:15
beunonot at the moment, but we will more and more14:15
beunoI have a few branches that start using it heavily14:16
beunobut most of the current javascript is still mootools, so I need to migrate code over14:16
Lo-lan-doIt's just that I also submitted bugs.debian.org/511286, which is a patch to use the YUI provided by the system.14:16
Lo-lan-doAnd the system currently only provides 2.5, so I wondered whether that would risk breaking because you use more recent features.14:17
beunoLo-lan-do, I suspect that libjs-yui isn't going to be YUI314:17
beunoright, 3.x and 2.x are incompatible14:17
beunoyeah :/14:18
Lo-lan-doI did some testing which seemed to work, but I don't know what YUI is used for so I didn't know what to test.14:18
beunoin general, we're going to be following YUI3 on the cutting edge14:18
beunoso as they release new versions, we will probably update the code14:18
beunoLo-lan-do, it works because the current code doesn't use YUI at all in trunk   ;)14:18
* Lo-lan-do grumbles about shipping copies of external code14:19
=== asac_ is now known as asac
SpadsI have a question about config files in-tree:  I have a default config file that I maintain with sensible defaults.  When I do a checkout, I often need to change this file for local development.  If I ignore the file in development, the .bzrignore gets mingled, and if I don't ignore it I just know I'll end up doing something dumb like publishing my database password.  How can I safely avoid transmitting conf file changes without telling the other ...14:54
Spads... branches to ignore this file?14:54
SpadsSo far I've just been grumbling and doing very selective commits on my development branches, but I just know I'll slip up at some point.14:54
kumiI usually maintain a separate .template file for that type of thing14:55
* awilkins was just about to say that14:55
kumiand remove the live config file from version control14:55
Spadshmmm.  Part of the point of having the defaults is that the app Just Works when you run it14:57
awilkinsI also implement this by having the app read both user settings and the defaults14:57
awilkinsAnd having user settings mask defaults14:57
awilkinsYou can then still have a user config file that you ignore but edit the defaults14:58
Spadshmm, I was really hoping for a bzr solution14:59
SpadsI mean, i've gone through ways I could change the app, and I'd rather not14:59
Spadssince the behavior of this config file comes from upstream tools14:59
awilkinsYou're asking for a way to version the file, but not version the file - I think that's a bit much to ask of a version control system :-)14:59
beunoSpads, what I do, is add the file the first time with example values, commit, ignore15:00
Spadsbeuno: and what do you do if you need to update the defaults?15:00
beunothen, we you want to re-structure it, commit it explicitly15:00
Spadsokay that sounds like a good way to go about it.15:00
beunoof course, that won't update the other branches15:00
beunobecause it's ignored15:00
Spadswell it's defaults15:01
awilkinserm... even if you ignore it, it will still notice changes if it's in the inventory15:01
Spadsawilkins: from a merge or pull?15:01
awilkinsignore only prevents new files being added implicitly15:01
SpadsI see15:01
beunoawilkins, ir tracking changes to it15:01
awilkinsbeuno: No, ignore does not stop it tracking changes15:03
beunoyou can't ignore a committed file...15:03
awilkinsbeuno: It only prevents "bzr add" adding it to the inventory15:03
awilkinsYou can ignore patterns that correspond to inventoried files but it will warn you15:04
beunoyeap yeap, I was wrong15:04
awilkinsAnd those files continue to be tracked15:04
beunoSpads, so, 2 options AFAIK:  1. use configfile.example, 2. use a Makefile and have those files ignored by default15:04
awilkinsThe only solutions to this AFAIK involve i) Being careful with commits (using shelves, looms, and discipline) - that always failes15:05
Spadsawilkins: yeah, basically that's where I'm at.15:05
awilkinsii) Not versioning live config files15:05
awilkins(in source, anyway15:05
awilkinsPeople version /etc and the like, but that's deliberate15:05
Spadswhat if in my devel version I did a bzr rm --keep first15:05
awilkinsThe file will stick around. If it's ignored, it won't be added to the inventory automatically. Changes will not be propagated to downstream branches15:07
awilkinsBecause they won't be versioned at all.15:07
SpadsI think this may be the safest way to do this then15:08
Spadsrm --keep it in production and development branches, and ignore it15:08
Spadsif that propagates to published branches, no harm no foul15:08
Spadseasily repaired15:08
Spadsno launch codes problems15:09
fdvare there anybody around who knows the merge / unshelve code?15:38
phinzeour dept switches to bzr today (!)16:16
phinzeso i may be around asking stupid questions :)16:17
mathrickbzr is awfully slow to start up17:12
mathrickbzr st on a non-repo takes at least 1.1s, after bzr and all is in the cache17:13
mathrickhg st on the same dir takes 0.7s cold and 0.07s hot :(17:13
beunomathrick, what plugins do you have installed?17:13
mathrickbeuno: sec17:13
beunomathrick, try the same without SVN17:15
mathrickbeuno: indeed, down to 200ms17:16
mathrickstill 2x slower, but it's much better17:16
mathricknow, why is bzr-svn so slow?17:16
beunoI'm sure if you run it with --no-plugins or something, it will take even less17:16
beunoloading plugins takes a bit more time17:16
beunoI think svn tries to open the branch even if it isn't svn17:17
mathrickyeah, I've had a couple of bugs because of it already17:17
mathrickbeuno: surprisingly, it takes 500ms with --no-plugins17:18
mathricksomehow ENOACCESS on ~/.bazaar/plugins is faster17:19
beunomathrick, that is suprising17:19
mathrick...and if I remove it, instead of chmod 000, it goes up to 700ms17:20
* mathrick files bugs17:20
jamhey phinze, great to hear it17:24
ronnyLarstiQ: sup?18:31
LarstiQronny: almost done with the flu18:31
LarstiQronny: you?18:31
ronnylaptop half broke18:31
ronnyok otherwhise18:31
ronnybut strugling with bzr again18:31
* LarstiQ tests his brain18:32
LarstiQyes, I seem to be able to think again :)18:32
ronnyi still cant find a good idea to map bzr's idea of repo -> directory branch to anyvc18:32
ronnythe model needs to fit well with git and hg18:32
LarstiQright, I see.18:33
ronnygoing around in cycles atm, but i need support for repo/branch creation, as well as bzrs "unique" view on pull vs merge18:33
ronnyits more fun to play around in prolog18:35
LarstiQronny: shouldn't pull/merge decompose easily over all three considering allowing/disallowing auto ehm, something with forward?18:35
ronnyLarstiQ: on git/bzr you can just pull without merge18:35
* LarstiQ suspects bazaar giving meaning to the left parent to be more of an issue18:35
ronnyeh git/hg18:35
LarstiQronny: even when diverged?18:36
ronnyit will just make multiple heads18:36
ronnysame goes for monotone18:36
LarstiQjust make a new branch?18:36
ronnythat would be messing with the users directory setup, kinda unacceptable, guess i'll just have to error out18:37
LarstiQis the the on disk result of what anyvc does important?18:37
LarstiQor will all interaction go through anyvc anyway?18:37
ronnyLarstiQ: never ever implicitly mess with users stuff18:37
LarstiQronny: I don't see hg/git being different here than bzr conceptually18:37
ronnyLarstiQ: also bzr is the only one that merges from a remote18:37
ronnyin git/hg you are in a workdir repo, pull in stuff, then merge heads18:38
ronnyin bzr you merge from the remote side18:38
ronny(which might occasionaly be a local branch in the same repo, but still a different dir18:39
ronnyand thats a BIG difference to deal with18:39
LarstiQif anyvc manages the collection of branches, what is wrong with adding a new one to the collection?18:39
ronnyits not expected to happen implicit18:39
LarstiQbut didn't the user explicitly say "anyvc-pull"?18:40
ronnybut pull != make me a new branch18:40
ronnyi guess i'll have to make pull error out just like bzr pull errors out on that case18:40
LarstiQronny: if you want a unified working, I think it needs to be18:40
LarstiQhg/git pull is more like that than bzr pull on a branch18:41
ronnyLarstiQ: from my point of view it would be unacceptable behaviour to create just another branch dir in the repo18:41
LarstiQthey operate on repositories instead of branches18:41
LarstiQronny: if the user is aware that is what is going to happen, why is it unacceptable?18:41
ronnythe 3 of them do not expose it in the fs, so its ok18:41
LarstiQas long as you don't stomp over existing stuff18:41
ronnyi  guess i can add a fetch operation that combines pull/merge for git/hg and does a merge for bzr18:42
LarstiQcan git/hg just pull on one branch?18:42
LarstiQand error on divergence?18:42
ronnythey dont error on divergence18:43
LarstiQronny: you need some clearly defined semantics :)18:43
ronnyyeah, guess i'll make up some logic18:43
ronnyLarstiQ: its a tricky hell (18:45
ronnyi'll cook up some prolog things to define the semantics and proof them18:46
* LarstiQ has no prolog experience18:46
ronnyprolog rocks18:46
ronnyhttp://ronny.uberhost.de/2009/1/7/how-to-mimic-sql-in-prolog <- my most recent toy18:46
ronnyit took ages to get the operators right18:47
ronnybut its cool :)18:47
LarstiQsql in prolog? dude :)18:48
ronnyjust the syntax18:48
ronnyi want to add a dml/ddl and do some analysis + a pseude-query-optimizer18:48
ronnydml = data-modeling-language (ie create *), ddl = data-definition-language (ie insert/update *)18:49
* LarstiQ nods18:49
LarstiQronny: does this have any impact on sqlalchemy?18:50
ronnyno idea, probably not18:50
cr3can I branch over http on launchpad?18:57
ronnyLarstiQ: hmm, another weird thing will be monotone19:01
ronnythey have repo + branches together (even unrelated branches) and the workdir is just refering to the repo19:02
LarstiQronny: how is that different from hgit?19:03
ronnyLarstiQ: you have n workdirs for each repo, not just one19:04
ronnythe repo is a sqlite db19:04
=== beaumonta is now known as abeaumont
ronnyneat, powerfull and slow as hell19:04
LarstiQso you have n workdirs, each refering to the _entire_ repo and having b heads?19:05
ronnyLarstiQ: each workdir refers to a revision in the repo19:06
LarstiQcan you commit in a workdir?19:07
LarstiQ(I hope so)19:07
LarstiQif so, it automatically moves to the new revision? And leaves all the other workdirs where they were?19:07
ronnyLarstiQ: yup, pretty much like that19:15
=== rocky1 is now known as rocky
verterokjelmer: ping19:37
verterokHi all!19:37
jelmerverterok: pong19:37
mathrickjelmer: bzr-svn makes bzr startup horribly slow19:38
verterokjelmer: maybe this is of your interest :). Bug #29071119:38
ronnyyo jelmer19:38
ubottuLaunchpad bug 290711 in bzr-xmloutput "bzr-xmloutput memory leak?" [Undecided,New] https://launchpad.net/bugs/29071119:38
mathrickis there any plan to fix that?19:38
jelmermathrick: are you sure? Last time I checked the majority of the startup time was in the launchpad plugin19:39
mathrickronny: doesn't that multi-workdir system of theirs cause problems? What problems does it solve, anyway?19:39
jelmerhey ronny19:39
ronnymathrick: monotone#s multi-workdir system causes no problems19:39
ronnyjelmer: having some issues mapping bzr to anyvc19:40
jelmerverterok: that's a known bug fixed in 0.519:40
ronnydifferences in the pull/push/merge concepts due to the lack of multiple heads19:40
verterokjelmer: oh, great!19:40
mathrickronny: but if you move one workdir, the others will have automatically diverged. That sounds like a recipe for disasters19:41
jelmerverterok: it would only happen by constant trying to open a location as a branch though19:41
jelmerronny: what do you do for e.g. svn?19:41
verterokjelmer: yes, the xmlrpc-service stays in memory and accept commands just like the CLI19:42
mathrickjelmer: I'm not sure anymore19:42
verterokjelmer: so it open the branch each time :/19:42
ronnymathrick: but its ok, you just use them like branches19:42
mathrickronny: oh, so workdirs have their own heads?19:42
ronnymathrick: there is basically no real difference in usage to a bzr repo with directory branches19:42
mathrickif so, calling them workdirs is misleading19:42
ronnymathrick: workdirs just point to revs19:42
ronnythe revs are in the shared repos19:42
mathricksure, but "workdir" for me is files on disk, not anything directly related to any repos or revs19:43
ronnyjelmer: no repo support for svn, it cant deal with most things, and there is no reliable way to deal with branches/tags19:43
jelmerronny: So fwiw, I've been working on multi-head support in bzr19:44
jelmerronny: for now, you should be able to just always report a single head19:44
ronnyyup, however i cant yet use the pull;merge workflow19:45
ronnyi guess i'll map it to fetch for now19:45
ronny(what git/hg do for combined pull/merge19:45
kumiHi folks, I'm finding bzr abnormally slow. I have this modest branch with 299 revisions, and I recently moved the remote server to a new location. I setup the new ssh keys and so forth, and tried a test push (a tiny change.) It took 15 minutes!22:52
kumiThen I committed another tiny change, and pushed again. This time it only took a few seconds.22:52
kumiWhat's going on?22:52
kumiDoes bzr detect a new location and scan through the entire remote branch history, or something like that?22:53
=== Mario__ is now known as pygi
Peng_kumi: Nothing odd should happen if you change the push location. My only guess is that you pushed to the wrong location, so it had to upload everything. (Anyway, I'm going AFK now. Sorry I couldn't really help.)23:01
Peng_kumi: Oh! If it's a large branch, or you're on a horribly slow internet connection, it may have decided to pack the repository, which would involve downloading and re-uploading a potentially significant amount of data.23:02
Peng_kumi: (I mean, it'll pack it occasionally no matter the size of the repository or speed of your connection, but if it's small and you have a fast connection, it shouldn't take long...)23:03
Peng_kumi: So anyway, I'm going to change my guess to "the repository was packed". It's just a coincidence that it happened when you moved servers.23:04
* Peng_ goes AFK23:04
Jc2kjelmer: yo23:08
Jc2kjelmer: i just cobbled together a front end for difflib.SequenceMathcher that emits the git delta opcodes used in packs23:10
kumiPeng_: thanks for the info. I actually just copied the .bzr from one server to another, and didn't do anything else. the repo is very small.23:25
kumiHow can I tell if a repo is packed? my local one reads:23:26
kumirepository: Packs 6 rich-root (uses btree indexes, requires bzr 1.9)23:26
kumiI guss that means it's packed? Can I unpack it, somehow?23:26
=== mark1 is now known as markh
kumiNevermind, pushing is quick now, and I don't plan to change push location again any time soon23:34
fullermdEr, if the branch were in a repo on the old server, and you just copied its .bzr, it DID have to push all the revs...23:49
enigmaHm...I'm seeing a strange bzr-svn error using 0.523:54
enigmabzr: ERROR: exceptions.AssertionError: Empty parent 'dfe-mon/branches' added, but child 'dfe-mon/branches/foo' wasn't added !?23:54

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