jam-laptop(it is just state based, and knows that key X follows key Y)12:02
mhaggerDoesn't it work by parsing rlog output?  Isn't that already ambiguous?12:02
jam-laptopmhagger: cvsps works by parsing rlog, I don't know the details on that side12:02
jam-laptop(As I work above cvsps, not below it)12:03
bialixmhagger: here some basic examples http://bazaar-vcs.org/Integrating_with_Bazaar12:03
jam-laptopThough I have some hooks to invoke cvsps with the "correct" arguments.12:03
jam-laptopI found the cvsps command line to be pretty ugly12:03
bialixand here http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.html -- epydoc like docs12:04
jam-laptopSo if your tree isn't too tricky, you can do "bzr cvsps-import CVSROOT MODULE OUTPUT" and not need to know anything about cvsps (other than have it available)12:04
mhaggerjam-laptop: Would you be interested in working together on this?  I bet we could have something done in a day or two12:04
jam-laptopmhagger: I would be happy to help when I can12:04
jam-laptopI work full time on the project12:05
bialixmhagger: just another question about cvsnt12:05
bialixcvsnt (as I say) have record about merge points12:06
bialixAFAIK before 1.5 svn does not record merges12:06
mhaggerjam-laptop: Do you work for Canonical?12:06
jam-laptopmhagger: yes12:06
bialixis this concept fit to current cvs2svn?12:06
mhaggercvs2svn doesn't try to deduce merge points, because there is no such info in standard CVS12:07
=== bialix wonder if name of project one day becomes cvs2any...
mhaggerWhat is the form of the mergepoint information?12:07
bialixI understand it, hence my question12:07
bialixsomething like this: mergepoint1     @;12:08
jam-laptopmhagger: so if you are interested in poking at it a bit, I'm guessing the only thing that would need to change would be to write a Parser to replace the cvsps Parser12:09
jam-laptopAs long as the "_PatchSet" objects can contain the information you want to copy over12:10
mhaggerjam-laptop: By "parser" I assume you mean "the huge amount of code needed to read RCS files and deduce the changesets"12:11
jam-laptopcvsps-import uses rcs to directly extract the texts, so it sort of depends on how cvs2svn extracts stuff12:11
jam-laptopmhagger: well the Parser takes cvsps Patches and turns them into meta-info plus a list of (file, version) data12:11
mhaggerMaybe we should move this to #cvs2svn to avoid disturbing the good folks of #bzr?12:11
jam-laptopmhagger: but you've already done all the work to do that part of the parsing12:12
jam-laptopmhagger: na, this is an open channel12:12
mhaggerYes, of course12:12
jam-laptopthe #bzr policy is to discuss anything even remotely related to #bzr12:12
jam-laptopunless the channel is extra busy12:12
mhaggerYes, we parse, then put everything in a dependency graph, then remove cycles in the graph, then topologically sort, and the changesets fall out.12:13
bialixbtw, cvsnt mark changesets with ids: commitid        44441d436f80000;12:13
mhagger...with lots of extra code for working with vendor branches, CVS's spurious commits, etc12:13
mhaggerbialix: Does the mergepoint indicate that all changes on the 1.5.2 branch through have been merged into that revision?12:14
mhagger...or only that the single delta has been merged, or what?12:14
mhaggerbialix: To support CVSNT...12:15
bialixbecause I don't have access to docs -- I can't say for sure12:15
bialixbut I can do some experiments12:15
bialixwith TortoiseCVS12:15
bialixto see what happens12:15
mhagger(1) The RCS parser would have to be enhanced a bit.  Currently it discards the newphrases12:16
bialixgenerally my TortoiseCVS workflow was very close to one we use in bzr12:16
bialixi.e. I'm always merge full branch history, not cherrypicking it12:16
mhagger(2) I think that CVSNT supports some other file modes (i.e., binary vs. text vs. keyword expansion etc)12:16
mhaggerThose would have to be supported.12:16
bialix2) -- I think so12:17
mhagger(3) The commitid information would have to be used.  I don't think this would be very difficult.12:17
bialix3) at least it could be used as suggestion?12:17
mhagger(4) Whatever different strange corner cases, corruption etc that exist in CVSNT repos would have to be dealt with.12:18
mhaggerYes, the most trivial thing to do with commitids is to use it as an exclusion criterion: if the commitids are different, then the revisions *cannot* be part of a single commit.12:18
bialixwhat do you mean by corruption?12:18
mhaggerThere are a few forms of CVS repo corruption that we have seen repeatedly.12:18
bialixah, ok12:19
mhaggerProbably resulting from CVS bugs in some historical version or something12:19
mhaggeror maybe poor disaster recovery12:19
mhaggerPresumably CVSNT has similar things12:19
bialixmay be12:19
bialixbtw, I don't remember, is cvs2svn supports CVS modules?12:20
mhaggerNot the modules file.  It is not clear what to do with it.12:20
mhaggerbut cvs2svn supports CVS repositories with multiple projects12:21
bialixin bzr we have concept of nested trees, but it still not production ready12:21
mhaggereach project can be converted independently of the others; for example, branches and tags in different projects can be considered distinct.12:21
jam-laptopmhagger: well, that and the fact that most people do manual surgery to rename files, etc12:21
jam-laptopAnd if you do it "correctly" you still have a bunch of cvsadmin work to do12:22
mhaggerOuch let's not even talk about that12:22
mhaggerOften there is too little left in the history to know what happened, so figuring it out is too much to ask of a conversion tool12:23
mhaggerMaybe it needs a "mechanical Turk" module :-)12:23
bialixmhagger: can you have some sort of description of real CVS format for ,v files?12:23
mhaggerbialix: man rcsfile is a good start12:24
bialixyeah, but this man is a bit short and unclear12:24
mhaggerSomewhere there is also documentation specific to CVS that describes their file extensions briefly12:24
bialixI mean: to understand what is standard CVS words, and what is cvsnt specific claims12:25
lifelesslo jam-laptop, welcome back to irc :)12:25
jam-laptophi lifeless, good to be around :012:25
mhaggerjam-laptop: I suggest that to get started you send an email to the cvs2svn dev mailing list with references telling us where to find cvsps-import and what modules to look at.12:26
bialix(jam was unhappy because there was no one to talk with, so we start to talk with ubotu) :-)12:26
bialixlifeless: ^12:26
mhaggerbialix: I don't know of better RCS file documentation.  Of course one could try to figure it out from the CVS source code.12:27
lifelessrcs source code :)12:27
mhaggerI've seen enough of them to understand them pretty well12:27
mhaggerWell, RCS files as used by CVS.  So you need to know both.12:28
lifelessmodules is well documented - new repos get a sensible modules12:28
mhaggerCVS uses its own RCS file parsing machinery, so I guess it is definitive.12:28
lifelessits runtime evaluated12:28
lifelessIIRC that is.12:28
lifelessanyhow, I haven't read all the backlog, would someone like to clue me in on the question quickly :) ?12:29
mhaggerWe're discussing the possibility of adding a bzr backend for cvs2svn12:29
mhagger(I'm the cvs2svn maintainer)12:29
lifelessthe cvs2svn script, last time I looked, was relatively easy to break with 'impossible' (but they happen) timestamp + ,v topological ordering combinations across files12:30
mhaggerlifeless: Then I guess the last time you looked was before cvs2svn 2.0 :-)12:30
lifelessI don't mean this as a criticsm btw12:30
lifelesssounds like its improved massively12:30
mhaggerThe new code uses a dependency graph to deduce changesets, and fixed all the known bugs in 1.x12:31
mhaggerIt uses quite a bit more RAM, but otherwise works very well.12:31
lifelessdoes it ever run incrementally, or is it a 1-shot tool ?12:31
mhaggerI don't know of a CVS repo that it can't handle12:31
mhagger1-shot, unfortunately.12:31
lifelesscscvs for all its flaws is incremental12:32
mhaggerMaybe a deep-pocketed sponsor could encourage an incremental conversion feature ;-)12:32
lifelessso it has extra state added to its output to allow incremental operation12:32
mhaggerWhat are the pros and cons of cscvs?  I'm not really familiar with it.12:32
fullermdI know every time it was tried on the BSD repo, it fell over.  That might have been pre-2.0, though.12:32
mhaggerFreeBSD works now.12:33
mhaggerThere are some problems with symbols being defined multiple times in a single file.  These have to be resolved manually using a "hints" file.12:33
fullermdThere's some Scary Shit(tm) hidden in there.  Any conversion that can swallow it deserves biiig kudos.12:34
mhaggerIt is not clear even how a perfect system would deal with corruption like that.12:34
mhagger(The repeated symbols, I mean)12:34
lifelessone is doomed to failure12:34
lifelessthe question is how close one wants to come to success ;)12:34
lifelessanyhow, cscvs, whats different - its geared for incremental runs, which means detecting ,v file moves and the like12:35
lifelessadded complexity12:35
lifelessmultiple front end and back ends12:35
mhaggerThere were some FreeBSD guys hanging around a couple of weeks ago (converting to git) and I'm pretty sure they were successful after I added the hints file workaround for their duplicated symbols12:35
lifelessits really vcs2vcs these days12:35
mhaggerWhat input/output formats does cscvs have?12:36
mhaggerI'm impressed by incremental conversions.  I've thought about how to add it to cvs2svn and it will be a good chunk of work.12:37
lifelessits nasty12:37
lifelessdon't :)12:37
mhagger[At least if your incremental conversions really work robustly!  It's easy to do a "works most of the time" solution.] 12:37
lifelessddaa and mwh know cscvs way better than I do these days12:37
lifelessbut reads-from svn, cvs12:38
lifelesswrites to bzr (we use this), tla (but we don't use this - it may be bitrotten now)12:38
mhaggerDoes it read arbitrary svn repos, or only repos that use the stylized trunk/tags/branches structure?12:39
lifelessso, cscvs is meant to break loudly if the incremental conversion looks horked, and let you manually correct the state, then resume12:39
lifelessoh, thats probably the other big difference12:39
lifelessits branch-at-a-time12:39
lifelessso any svn repo, you just identify the path to convert12:40
lifelesswhat else is interesting12:40
mhaggerCVS is also branch-at-a-time?12:40
lifelessoh yeah, there is pure python cvs wire protocol implementation in there12:40
mhaggerHmmm, that's curious12:40
lifelesscscvs was originally written for a vcs which had no concept of free-form branch naming12:41
=== mhagger thinks about whether that simplifies conversions significantly
lifelesslong as you convert the parent branch[es]  first, and provide a way to find them12:41
mhaggerIt sure must reduce the computational resources needed for a conversoin12:41
lifelessthats one area could do with improvement actually12:42
fullermdHere's a Q: How easy would it be to use some of the properties work planned/done to store up info on file rev sources, so I could "bzr find src/foo.c cvsrev:1.234"?12:42
lifelessfullermd: theres a header in the revision already12:42
lifelessfullermd: have a look at one of the cvs conversions on launchpad12:43
mhaggerOK it's bedtime in Berlin...12:44
mhaggerLet me just repeat my offer:12:44
mhaggerIf somebody with bzr experience is willing to join forces, I'd be happy to work on a bzr backend for cvs2svn.12:44
lifelessI'm happy to answer any questions and sketch out the right bits of the bzrlib api to use12:45
mhaggerIt shouldn't be more than a couple of days work12:45
lifelesswe should have everything you might want already present12:45
bialixif it's possible to have some progress with merge points, I can help12:45
fullermdlifeless: Know one of them offhand?12:46
lifelessdrop me a mail if you like, describing what the backend ends - 'robert at canonical'12:46
mhaggerI mostly don't have time to find everything and learn all of the bzr concepts12:46
lifelessfullermd: no12:46
lifelessand I'll come back to you with a brain dump and such12:46
mhaggerOK, thanks lifeless12:46
mhaggerI'll try to get to it in the next couple of days.12:47
mhaggerIf you are interested, meanwhile look at cvs2svn source files cvs2svn_lib/git_output_option.py and git_repository_recorder.py12:47
lifelessI am swamped :(12:48
mhaggerI guess what you need will be pretty obvious by analogy12:48
lifelessI'm racing against the next release clock to get my performance impoved repository merged12:48
mhaggerGoodnight, thanks for the interesting conversation!12:48
=== mhagger is now known as mhagger-afk
lifelessI think I have one bug left in this bisection work12:56
lifelessand it will be done12:56
=== fog [n=fog@debian/developer/fog] has left #bzr []
jelmerhmm,     'InventoryDirectory' object has no attribute 'snapshot'01:11
lifelesscommit builder has that logic now01:12
lifelessfaster, more tightly coupled to the repository so different repos can do different things01:12
=== p4tux [n=p4tux@] has joined #bzr
=== poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr
lifelessI think I am going to factor out a ParsedRegions class01:22
lifelessonce I fix this bug01:22
pooliegood morning01:27
pooliei'm feeling much better today01:28
pooliei made some progress on commit01:28
lifelessI'm a tad seedy01:28
pooliei suspect a bug in how update_base_.... interacts with the inventory cache01:28
lifelessand horms wedding party is tonight01:28
=== BasicOSX [n=BasicOSX@] has joined #bzr
lifelesspoolie: what sort of bug?01:30
pooliesomething like the inventory and dirstate being out of sync01:31
poolieit's just a gut feeling so i don't want to debate if it's likely or not01:31
pooliei'm just going to see if the same test fails on other wt formats01:32
lifelessfair enough01:34
pooliewhat i see in particular is that01:35
pooliean apparently correct delta is passed in,01:35
pooliebut when the test looks at the inventory later, some files have not been removed01:35
lifelessso its looking at the inventory of the parent?01:36
lifelessor the inventory of the tree?01:36
pooliethe test is looking at the wt inventory iirc01:36
lifelessthat would be a bug01:36
poolieyes, apparently01:37
lifelessin the test - because the update_...delta() method is meant to update the parent tree01:37
poolieanyhow, that was what i suspected last night01:37
poolieof course01:37
pooliebut really we seem to need something that both updates the parent tree and also the wt01:38
lifeless(you can see the method being tested in bzrlib.tests.workingtree_implementations.test_parents)01:38
lifelesswhy do we need to update both? updates to the current tree can be done directly in dirstate representation01:39
=== m0rra [n=m0rra@84-50-8-237-dsl.mus.estpak.ee] has joined #bzr
lifelesspoolie: unless there is a performance problem, it seems cleaner to me to do the wt changes and the basis tree changes separately; and theres no performance problem I see doing it separately01:44
pooliehang on01:44
pooliei think you're right, i was expecting it to update both of them the same way01:45
pooliewhich is not quite sensible01:46
pooliei agree you can probably do it efficiently with two separate calls01:46
lifelessthe wt changes are uncommon01:47
lifelesswhereas the parent changes always01:47
poolieright, only for autoremove and similar things01:47
m0rraumm. hasn't the documentation been updated for a long time or what..? instead of bzr in the documentation, i need to use baz. also it shows the latest version is 0.91, but i have 1.4.2 and all the commands are different.?01:47
lifelessm0rra: 'baz' is a very old tool01:47
lifelessm0rra: I think you have the wrong software package installed somehow01:47
lifelessm0rra: if you are on ubuntu/debian install 'bzr'.01:48
pooliewe should fix that package naming01:48
pooliethere is a bug for it01:48
m0rraah, i see. i apt-get installed bazaar...01:48
poolieok, i see the problem01:48
lifelessfood time for roberts01:49
lifelessDo you want a morning sync; I have plenty to do without syncing01:49
poolieme too, i'm just going to persist with this01:49
poolieonly question would be, do you want me to declare a freeze, declare a slip, do nothing?01:50
=== igc [n=igc@ppp121-45-195-124.lns1.bne1.internode.on.net] has joined #bzr
=== jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr
jmlwhy is build_tree in TestCaseInTempDir and not TestCaseWithMemoryTransport?01:58
pooliehi jml, igc01:59
jmlpoolie: hello01:59
pooliejml, i can't see a good reason why01:59
igchi poolie01:59
pooliewithMemoryTransport is robert's invention, he may be able to help when he gets back01:59
lifelessthose raisins are hysterical02:00
jam-laptoplifeless: doesn't 'build_tree' build on disk02:00
pooliehi jam-laptop02:00
lifelessdisk or transport02:00
jam-laptopAnd "WithMemoryTransport" doesn't have a disk location?02:00
lifelesscan do either02:00
lifelessMemoryTransport still has local disk, because of the bug where we write config files02:01
lifelesswhen you do anything02:01
lifelessand also because posix makes it hard to chdir /nonexisting/path :)02:01
lifelesspoolie: release wise - your call, I'm fine however you play it02:01
=== m0rra [n=m0rra@84-50-8-237-dsl.mus.estpak.ee] has left #bzr ["<surnuaed>]
jelmerlifeless: Btw, any news on my pqm patches - or should I wait until after 0.92 before asking you about those again?02:08
=== bialix [i=chatzill@] has joined #bzr
lifelessjelmer: yah, wait a bit02:25
lifelessvery single-track right now02:25
=== jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr
=== mlh [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr
=== fbond [n=fab@pool-71-169-154-64.burl.east.verizon.net] has joined #bzr
lifelesssomeone has disputed the neutrality of the bzr wiki page02:49
lifelesssimply because it doesn't list cons02:49
bialixpros and cons03:01
=== jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr
bialixbzr has only pros03:01
spivbialix: I wish :)03:04
=== pete__c_ [n=pete@032-437-364.area7.spcsdns.net] has joined #bzr
spivbialix: then I'd have no work to do ;)03:04
keirhmm, if i bzr push to a bzr+ssh server that doesn't exist, it shouldn't bail with a 20 item traceback, should it? it sais ssh: projects.launchpad.net not found; then a huge traceback follows03:04
bialixno, we work on new features, to increase amount of pros ;-)03:04
bialixno should not03:05
keirlifeless, which wiki page?03:05
bialixthere is bug report about this03:05
bialix!ubotu fas03:06
ubotuSorry, I don't know anything about fas - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi03:06
bialixstupid ubotu03:06
bialix!ubotu traceback03:07
ubotuSorry, I don't know anything about traceback - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi03:07
=== orospakr [n=orospakr@bas4-ottawa23-1177612037.dsl.bell.ca] has joined #bzr
bialixnever mind03:07
spivkeir: no, it shouldn't, I think there's a bug open about that.03:07
spivOh, as bialix said :)03:08
bialixkeir: it's also traceback when your connection suddenly dropped and some more unpleasant things03:09
keirthat's not very nice03:09
bialixjam-laptop: ping?03:09
=== yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr
i386hey lifeless03:14
i386I managed to crawl into work03:14
lifelessI was working at the usual time :)03:15
lifelesskeir: wikipedia's 'Bazaar_(vcs)' page03:15
i386lifeless: I think I may go home03:16
i386apparently Jaq didnt turn up for work this morning03:20
=== bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr
=== Verterok [n=ggonzale@75-108-235-201.fibertel.com.ar] has joined #bzr
=== jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr
=== pete__c [n=pete@032-437-364.area7.spcsdns.net] has joined #bzr
=== marianom [n=marianom@ubuntu/member/marianom] has left #bzr []
=== poolfool [n=mchaffin@c-71-196-179-226.hsd1.co.comcast.net] has joined #bzr
=== adhoc [n=kim@ppp121-45-74-196.lns10.adl6.internode.on.net] has joined #bzr
adhochi guys...04:22
adhoccan i use bzr with an authenticated web proxy ?04:22
lifelessvila will really know04:26
lifelessbut I think you can yes04:26
=== jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr
=== AfC [n=andrew@m770f36d0.tmodns.net] has joined #bzr
jam-laptopspiv: ping04:43
spivjam-laptop: pong, although I want to get some lunch in a minute04:47
jam-laptopspiv: k, I just wondered if you had any ideas about trying to track down memory leaks in python04:52
jam-laptopand what the gc.set_debug() flags really mean.04:52
jam-laptopFeel free to respond to my email04:52
jam-laptop(I'm worried I'm setting a refcount incorrectly, and wondering if gc.collect() can tell me about that sort of problem)04:52
jam-laptopIt sounds like it can, but I'm not positive what everything means04:52
lifelesshi jam-laptop long call ?04:54
jam-laptopabout 1 hr04:56
jam-laptopjust dealing with other stuff04:57
spivjam-laptop: I'm not very familiar with the precise meanings of the various gc.DEBUG_* flags.04:58
spivjam-laptop: although if you're worried about refcounts, perhaps sys.getrefcount or gc.get_referrers may help you test hypotheses.04:59
jam-laptopwell reading http://www.python.org/doc/current/lib/module-gc.html04:59
=== igc food
jam-laptopseemed relevant04:59
spiv(I'm not sure, but I'm guessing that Pyrex would tend to generate objects that play nicely with get_referrers)04:59
jam-laptoptyping is slow with a baby in one arm Z)05:00
spivRight, everything I know about those flags I learned from that page :)05:00
spivWell, I guess I could spend some quality time with Modules/gcmodule.c ;)05:01
jam-laptopdon't worry about it too much05:07
lifelessspiv: so is your reconcile patch landed?05:14
=== jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr
=== jamesh__ is now known as jamesh
=== poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr
lifelessso who is dogfooding05:48
lifelesspacks that is05:48
lifelessmwhudson: ping05:48
fullermdbzr.dev is edgy enough for me...05:50
lifeless    def all_revision_ids(self, transaction):05:53
lifeless        """See RevisionStore.all_revision_ids()."""05:53
lifeless        rev_file = self.get_revision_file(transaction)05:53
lifeless        return rev_file.get_ancestry(rev_file.versions())05:53
lifelessthats a WTF moment right there05:53
=== jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr
poolie_Subject:  Should we baptized "in the name of the Father, Son, and Holy Spirit" or "in Jesus' name"?05:59
poolie_now that is offtopic05:59
poolie_"either, as long as it is a utf-8 name"06:00
fullermdSounds like a difficult debate.  We should compromise and do it in my name instead.06:00
lifelessI just managed to trip a md5 has collision on pull06:00
lifelessyeah, packs with the same data have the same content :)06:02
lifelessso the question is why I'm copying this data at all06:03
lifelessigc: poolie_: jam-laptop: partial-index-using packs pushed to my usual 'repository' branch06:06
=== bratsche [n=cody@adsl-68-94-34-240.dsl.rcsntx.swbell.net] has joined #bzr
=== bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr
=== jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr
poolie_(reading ian's paper)06:35
lifelessah, I think I know06:44
lifelesssee if this scans06:44
lifelessdo a commit, adds a revision that triggers autopack06:45
lifelesssomething causes a failure right there06:45
lifelessmm more detail06:45
lifelesswe autopack06:45
lifelessadd the new pack and its indices06:45
lifelessthen start removing the obsoleted packs06:45
lifelesswhich is where it breaks06:45
lifelessthe result is that we have a set of packs, which when packed generate the same pack again06:46
lifelessand that new pack is already present06:46
lifelessif this theory is right06:48
lifelessdoing a manual pack will let me pull bzr.dev06:48
lifelessbecause it doesn't aim for the log distribution06:48
igcthanks lifeless06:49
lifelessspiv: what did you think of my python bug ? :)06:50
lifelessyup, doing a pack let it work06:50
lifelesswow, performance jump :)06:51
spivlifeless: cute06:53
lifelessspiv: is your reconcile patch ok'd ? and merging ?06:54
=== jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr
lifelesspoolie_: igc: spiv: requesting a review of the index bisection patch.07:00
lifelessThis is the last patch needed to send in a patch adding packs.07:00
poolie_hm, how big is it?07:01
=== poolie_ rolls up his underscore sleeves
=== poolie_ is now known as poolie
lifeless NEWS                              |   1007:02
lifeless bzrlib/bisect_multi.py            |   64 ++++07:02
lifeless bzrlib/index.py                   |  504 ++++++++++++++++++++++++++++++++++++--07:02
lifeless bzrlib/tests/__init__.py          |    107:02
lifeless bzrlib/tests/test_bisect_multi.py |  344 +++++++++++++++++++++++++07:02
lifeless bzrlib/tests/test_index.py        |  290 +++++++++++++++++++++07:02
lifeless bzrlib/tests/test_knit.py         |   1207:02
lifeless 7 files changed, 1198 insertions(+), 27 deletions(-)07:02
keirsweet, we have patch markers now?07:02
pooliei imagine he ran diffstat by hand07:03
poolieit would be nice if send did it though07:03
keiroh, i didn't know that command existed07:03
lifelesskeir: 'bzr send -o- | diffstat'07:03
lifelessalso there is a diffstat plugin07:03
lifelessbut I haven't used it so can't comment07:03
=== fullermd still misses CVSish +/- in log :|
lifelesskeir: my repository branch now does the naive bisection robustly07:04
keirlifeless, niiice!07:04
pooliefullermd, i can't remember what that is07:04
lifelesskeir: looks like there is *tonnes* of room for improvement on this though, with the design we've been batting around07:05
keirlifeless, yeah, i like the differential encoding of the hash table07:05
pooliei'll read that patch then take a break i think07:05
keirlifeless, it's a nice little trick07:05
fullermdrevision 1.707:05
fullermddate: 2006/01/21 01:17:04;  author: mfuller;  state: Exp;  lines: +29 -707:05
lifelessI think that + topological grouping on the first graph, is going to be quite a huge win07:06
keirlifeless, i agree totally07:06
fullermdEasier on my eye than diffstat for a quick glance at magnitude.  Maybe that's just familiarity, but...07:06
lifelessfullermd: per-file07:06
keirfullermd, i def. prefer diffstat07:06
keiri'd even like to get diffstat by default on commit and such, but i'm crazy07:07
poolielifeless, is it possible at all for lookup_keys_via_location to be split up?07:07
poolieor _parse_region for that matter07:07
keirlifeless, on a slightly different note, i've been trying to figure out what i don't like about the bzr dev docs07:07
lifelessfullermd: also, you know about diffstat's format parameter ?07:07
lifelesskeir: I think the diffstat plugin may do that07:08
fullermdI s'pose once I dig into writing commit mailings on bzr, I'll end up having to get my brain on diffstat, since it exists and a straight +/- doesn't.07:08
lifelesskeir: if it doesn't, you can definately do a post-commit hook plugin to do it07:08
keirlifeless, and it's that there isn't a clear description of the underlying data structures but absenting implementation details07:08
keirlifeless, in a self-contained and digestible form07:08
fullermdlifeless: I've looked through the manpage; didn't see anything that would give me that sort of output...07:08
lifelesspoolie: _parse_region is about 10 lines, are you looking at the updated patch ?07:08
pooliei'm looking at the current one in BB07:09
keirlifeless, i've done all this thinking about how to do nicer indicies and whatnot, and really, i still don't understand how _everything_ is structured07:09
lifelesspoolie: thats the old one07:09
pooliethump bb on the side :)07:09
lifelessactually list sluggishniss07:10
lifelessits not in my mailq07:10
poolieok, i'll check again soon07:10
poolieam going to get fresh air first07:10
poolieif that's ok07:11
lifeless /wave07:11
lifelessfullermd: so there is a -f option07:12
lifelessfullermd: but none match your desire. However.. the good news is its open source07:12
lifeless:) :) :) :) :)07:12
lifelessalso, we have a pure python version in the diffstat plugin I believe, that would be easy to do cvs style summaries07:12
lifelesskeir: I think thats a good point; and one we're incrementally achieving with the doc/developers/ text files07:13
keirlifeless, but (apologies for being blunt) the dev docs are _all over the place_07:13
lifelesskeir: if you've read the doc/developer/repository.txt file from the pack branch07:13
keirthe HACKING file is very good07:13
keirbut the other stuff is... a bit of overload for starting out07:13
lifelessblunt is fine :)07:14
pooliekeir, you could usefully point out 'doc/developer/something is crack'07:14
poolieto provoke people to clear up or remove it07:14
lifeless'where do I go to get XXX' ?07:14
lifelesswhich will either get better references made07:14
lifelessor a bug saying we're missing that07:14
keirwhat i want is a 1 or 2 page summary of the data structures i need to reason about in bzr07:14
keirand their relations07:14
keirfor example. in repositories.txt, i expect to see a description of what repositories _are_ before going into the requirements of their commands!07:16
keirwhat data is in it?07:16
keirwhat are the types?07:16
keirtheir relations?07:16
lifelessI think there are two separate things here07:16
keireverything in that file should go in repository_scaling_considerations.txt07:16
lifelessone is the interface07:16
lifelessthe other is the implementation07:16
lifelessmuch of what you are asking is implementation specific07:17
keiri don't think so07:17
lifelessand is/should be accessible by 'pydoc bzrlib.repofmt.pack_repo'07:17
keirfundamentally, bzr stores a bunch of DAG's with data tied to the edges / nodes07:17
=== jamesh__ [n=james@canonical/launchpad/jamesh] has joined #bzr
lifelessthe bzr-svn repo fmt does not store the same dags at all07:18
keirsure, bzrlib exposes an API for manipulating and accessing that format07:18
lifelessmeltdown ? :)07:18
keirthis is what i mean07:18
fullermdRun!  Run while you still can!07:18
keirwhat i like about git and mercurial, is that i can easily understand the structure07:19
lifelessbzr-svn is expected to meet the same interface07:19
keirso reading and understanding the code is a snap07:19
lifelessand we should document the interface in the manner you are talking about07:19
lifelessI agree we have a problem here07:20
keiri keep going back to mercurial's dev page: http://www.selenic.com/mercurial/wiki/index.cgi/Design07:20
=== adhoc [n=kim@ppp121-45-74-196.lns10.adl6.internode.on.net] has left #bzr []
keirhonestly, my lack of understanding this stuff has made me less inclined to believe bzr is fundamentally better than the competition07:20
keiri really do agree with linus on 'get your data structures right; code comes and goes'07:20
keirand if bzr doesn't have it's data structures straight and documented... it's a bit scary07:21
keiri'm sure it's all sensible, but it's a big black box from the outside07:21
keiri've even read lots of the docs and hacked the code!07:21
lifelessI think that data structures come and go to07:21
lifelessthere is a higher cost in changing your mind07:22
spivThat doesn't mean we shouldn't document them clearly, though :)07:22
lifelessbut only a god can predict what the data structure needs to be at the start of a project07:22
keiri agree07:22
keirbut nevertheless, perhaps the lack of documenting data structures and a bigger focus on api is what helped hg become 'preferred' in some sense, because it is much faster at network and most other stuff?07:23
lifelessso anyhow, we have varying degrees of quality here, on different things written at different times07:23
=== keir is ranting a bit :P
keirplease take everything i'm saying with a grain of salt07:23
lifelessI think being faster at network and disk is much more noticable to users :)07:23
lifelessnote that you simply cannot do most things with hg over the wire07:24
lifelesswire level its push/pull only07:24
keirbut regardless, hg seems to have hit the sweet spot07:24
lifelesswell it hit a sweet spot, for some things07:24
lifelessthey have made compromises I consider unacceptable07:24
lifelesslike the 'fail to notice sub-stat-size-preserving granularity changes'07:25
lifelessand the renames are always heuristics07:25
keiranyway, i didn't want to start a hg debate07:25
lifelessand these things have come about, IMNSHO, because they put performance first and everything else has been assessed against that from day one07:25
keirmainly i want good docs on just what is stored in .bzr07:26
keirat the level of abstraction exposed by the api07:26
keirin form that lets me reason about how it might be represented on disk07:26
keiri understand both what git is storing and how it's storing it07:27
keirand i spent faaar less time with git!07:27
fullermdIt's just that in git you can't figure out the commands to do stuff with it   ;)07:27
keirfullermd, yes. i am not saying git is better in usability.07:27
lifelessthis is pre-the-recent-doc-layout-change07:28
lifelessbefore we were putting all docs into the tree07:28
lifelessbut I was working towards basically what i think you want in that wiki-space07:28
lifelessits most definately not enough, but if its in the right direction, please say so07:28
keiri want gratuitius pictures with arrows :)07:29
keiri might even make them07:29
keirif i knew what to draw07:29
=== bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr
=== keir reads
keiron the WorkingTree page07:30
keirthe part 'basis inventory'07:30
keiris _exactly_ what i'm looking for but in much more detail07:30
lifelessbbiab, need to walk in circles and think about locking07:31
keirthe 'pending merges' should be 'an ordered list of secondary parents (aka, [revid] *) to give the next commit.07:42
keir(also on Classes/WorkingTree)07:42
keirmaybe i'm crazy, but i want less english and more syntax :P07:42
keirso the revision history for a file is a sub-graph of the revision graph, correct?07:43
lifelessthe nodes are a subset07:44
lifelessand the edges follow the same reachablility rules07:44
lifelessthat is if A is reachable from C in a per-file graph07:44
lifelessthen A is reachable from C in the revision graph07:44
keirnow, is that an implementation by-product? i'd vote to describe that07:44
lifelessso the file graph is C:[A] 07:44
lifelessbut the rev graph is07:45
lifelessC:[B] , B:[A] 07:45
lifelessthis is a model, its part of the interface07:45
lifelesshow you store/if you store is implementation07:45
keiryes, of course07:45
lifelesstheres a proof of this I sent to the mailing list a few weeks back FWIW07:46
keirseen this: http://eagain.net/articles/git-for-computer-scientists/ ?07:46
lifelessno browser handy sorrry07:49
keirvt100 got you down?07:49
lifelessno, the mozilla tree doe07:50
lifeless550MB of source07:50
keiroh wow07:50
lifelessits what I profile with07:50
lifelesssmaller trees are too quick, not enough granularity from the profiler07:50
fullermdYou probably have.  It's the usual "there are blobs, and there are things that point at blobs, and things that point at things that point at blobs, and..." git exposiiton.07:50
lifeless'I have a database thanks bye'07:51
lifelesspoolie: patch has hit the list now; evo was retarted on me07:51
=== lilr0bbie [n=lilr0bbi@c58-107-243-71.sunsh7.vic.optusnet.com.au] has joined #bzr
lifelesswhat does everyone think about replacing 'knitrepo.py' with 'knits.py' and 'weaverepo.py' with 'weaves.py'07:52
lifelessspiv: oh, and ping, can we chat on the phone about lock tokens and packs ?07:52
lilr0bbieumm.. i was wondering if anyone could help me with problems using bzr on an ntfs fuse-mounted system?07:53
lifelessfullermd: this ones for you07:53
spivlifeless: sure, just a sec07:53
keirwhat does a revision have in it07:53
fullermdlilr0bbie: Attribute changes?07:53
keira list of parents; a list of chaged files (as fileid's? what's a fileid?)07:54
lilr0bbiefullermd: thats the one07:54
lifelesskeir: parents, properties, commit message07:54
lilr0bbiefullermd: i have searched for solutions using google but none unfortunately07:54
fullermdOh good.  I identified the problem, now somebody else can handle the solution side   :)07:54
lilr0bbiefullermd: argh lol... i am fearing atm that there is none...07:54
spivlifeless: I'm probably about +0 on that file renaming, fwiw.07:55
fullermdI'm not sure there is one, actually.  If all the files in the branch have the same (all +x or all -x), you might be able to change mount options to make it work right...07:55
lilr0bbiefullermd: I will try that...07:55
fullermdAnother option would be to use the branch part of that branch (the VCS data), but use a working tree somewhere else and not touch the NTFS-mounted WT.07:56
keirlifeless, http://bazaar-vcs.org/DataStructures07:57
keiris the revision ID included in the revision also? as in the sequential numberings08:00
fullermdrevno you mean (not revid).  I don't think that's "included" anyway, just derived whenever; it's not consistent for the rev, so...08:00
keirso how are the changed files in a particular revision modeled?08:01
keirif a revision only has parents, properties, and a commit message08:02
=== keir drops a pin
lifelessyou do a diff between inventorie08:09
lifelessfor a revision id X, there is an inventory X08:09
lifelessthe 'changes in X' really is code for 'the delta from X.parents[0]  to X'08:09
keirso what's in an inventory?08:12
keirsnapshots of file contents?08:12
lifelessinventories map paths to fileid:content_version08:17
lifelesse.g. /foo -> 'foo_id':revisionid08:17
lifelessalso they hold some inline things like the execute bit, symlink targets08:17
lilr0bbiefullermd: i found a way to make it work.  I need to force the ntfs drive to mount with full permissions (i.e., fmask=0,dmask=0) in order to allow this to work, then it seems to "ignore" the fact that it can't set the permissions properly08:17
lifeless'foo_id':revisionid there, is the key used in the .tix indices to retrieve texts08:17
keirfileid:content_version is like (fileid, revid)08:18
lifelessyes, I'm just changing syntax to confuse you08:18
keirlifeless, http://bazaar-vcs.org/DataStructures08:19
keiryou can see where i'm going08:19
lifelessno browser ?08:20
keirso the inventory split is exposed at the API level?08:20
keirlynx is sufficient08:20
keirlinks rather08:20
lifelesswhat do you mean 'split' ?08:20
keirinventory / revision08:20
keiri have to run :( i'll come back and chat about this later08:20
lifelessrevision objects are git commit objects08:20
keirbut i want to fill out this document08:21
lifelessinventory objects are hg manifests08:21
lifelessdo we have a handy three-way-diff-of-arbitrary-sequences?08:28
lifeless3merge I mean08:28
=== hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr
=== herzel104 [i=herzel@gateway/tor/x-d0b2a37c4659c381] has joined #bzr
pooliekeir, can you please turn that wiki page into a doc patch at some point?08:42
=== BasicOSX [n=BasicOSX@] has joined #bzr
=== cfbolz [n=cfbolz@p54AB80E9.dip0.t-ipconnect.de] has joined #bzr
mwhudsonlifeless: pong?09:29
fullermdGreat, look what you did...09:33
mwhudsontee hee!09:34
=== Mez is now known as Mez|Away
=== mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr
=== mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr
=== RichardL [n=Skippy@] has joined #bzr
=== smartGPX [n=smartGPX@84-12-25-202.dyn.gotadsl.co.uk] has joined #bzr
=== i386 [n=james@ppp239-169.static.internode.on.net] has joined #bzr
=== mvo [n=egon@p54A6459C.dip.t-dialin.net] has joined #bzr
=== mhagger [n=mhagger@ssh.berlin.jpk.com] has joined #bzr
=== mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr
=== smartgpx [n=smartgpx@pc585.cc.le.ac.uk] has joined #bzr
smartgpxGood morning. Is it appropriate to seek help with a 'broken' branch here?11:03
=== Mez|Away is now known as Mez
quicksilveralthough I'm not the person who can help you :(11:13
smartgpxRunning bzr v091 on winXP. I have a simple 'personal branch' [bzr-versioned working tree]  that cannot be copied/cloned with the 'bzr branch' command. Fails with bzr: ERROR: Unable to delete transform temporary directory.11:34
=== bac [n=bac@canonical/launchpad/bac] has joined #bzr
=== mvo [n=egon@p54A6459C.dip.t-dialin.net] has joined #bzr
smartgpxThe destination working tree is not populated. There are 4 files in limbo, but far more than this in the source tree.11:37
quicksilverhave you always used it on winXP?11:45
quicksilveror was it ever on another OS ?11:45
fullermdI think that's come up before.  Case-related, maybe?  Dig around the list archives (I don't know anything beyond a vague memory of it being discussed before)11:46
quicksilveryeah, that's what I was probing at with other OSes11:50
quicksilverif you have two files identical other than case, OSX and XP will get very confused11:51
quicksilver(we have lots of OSX machines runnin bzr here)11:51
=== APXAHGEJI [n=user@wn2nat53.beelinegprs.ru] has joined #bzr
=== APXAHGEJI [n=user@wn2nat53.beelinegprs.ru] has left #bzr []
smartgpxThe branch has only resided on one machine. OS has been Win XP throughout. Branch +working tree was originally developed during 4Q06 using bzr at about v0.10.12:10
smartgpxRecently moved bzr to v091 and I think I was prompted to upgrade the branch? Might that have introduced a problem?12:11
=== bratsche [n=cody@adsl-68-94-23-66.dsl.rcsntx.swbell.net] has joined #bzr
quicksilvercan you clone old versions?12:24
quicksilverbzr branch -rXYZ foo new-foo12:24
quicksilvertry for a few different revisions, from very old to quite recent12:24
smartgpx"bzr branch -rXYZ foo new-foo"  Interesting tip - I'll give it a try next time I'm at that machine.  Thanks for now. DJ12:29
=== nir [n=nir@moinmoin/fan/nir] has joined #bzr
=== mhagger is now known as mhagger-afk
metzehi *01:24
metzehow can I disable the process bar on bzr 0.8.2?01:25
=== mhagger-afk is now known as mhagger
=== mhagger [n=mhagger@ssh.berlin.jpk.com] has left #bzr []
=== EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #bzr
=== fog [n=fog@debian/developer/fog] has joined #bzr
PengThere were progress bars in 0.8.2? I would've thought they were newer.01:49
=== vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net] has joined #bzr
=== corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr
=== mrevell is now known as mrevell-lunch
=== niemeyer [n=niemeyer@200-138-54-64.ctame705.dsl.brasiltelecom.net.br] has joined #bzr
=== mwhudson_ [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr
=== cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr
=== quicksilver [n=jules@] has joined #bzr
=== corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr
=== luks [n=lukas@unaffiliated/luks] has joined #bzr
=== corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr
=== fbond [n=fab@pool-71-169-154-64.burl.east.verizon.net] has joined #bzr
vilajam-laptop: pong (finally)02:43
=== mrevell-lunch is now known as mrevell
=== mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr
=== smartgpx [n=smartgpx@pc585.cc.le.ac.uk] has joined #bzr
=== metze is now known as metze_away
=== metze_away is now known as metze_asleep
=== orospakr [n=orospakr@bas4-ottawa23-1177612037.dsl.bell.ca] has joined #bzr
smartgpxFAO: quicksilver Re: 'broken' branch. I think you were right about it being a case-differentiation problem.03:43
jam-laptopmorning vila03:43
vilajam-laptop: morning ! How are you and how goes the family ?03:43
jam-laptopall in all, things are going well03:44
smartgpxThe first commit after the last one that will unpack correctly  has this - amongst other changes:03:44
jam-laptopwe aren't completely exhausted all the time :)03:44
jam-laptopI had a quick question for you on the new ConfigObj03:44
vilahehe, I know that :)03:44
vilaseen the new bug ?03:44
jam-laptopI believe I'm seeing it have cycles (and thus not get properly garbage collected)03:44
jam-laptopvila: bug 151208?03:45
ubotuLaunchpad bug 151208 in bzr "util/configobj should be deleted" [Undecided,New]  https://launchpad.net/bugs/15120803:45
smartgpx"  removed: ReadFile.FEC  - added:   ReadFile.fec"03:45
jam-laptopI was just wondering if the new version did anything about that. (I'm guessing not)03:45
vilayes, still want a more detailed summary ? I can re-read the web page, but I think if you want more details than "it passes the test suite" you can... wait... you're searching a bug fix for your gc pr isn't it ?03:46
=== vila still can't read while typing ;-)
vilaI doubt it does, but I can double-check, but if you can reproduce your pb, just download the latests version and install it it's only one file, no zip no nothing03:48
vilaseems the quickest and best check to me03:48
smartgpxIf that really is the cause of the problem (which new readers might like to know is "bzr: ERROR: Unable to delete transform temporary directory ..../.bzr/checkout/limbo. - then is there a way to unravel the problem retrospectively?03:49
jam-laptopI figured a quick check with you would be good :)03:52
jam-laptopI doubt it is the overall problem03:52
jam-laptopjust something I encountered03:52
=== sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr
vilajam-laptop: just re-read http://www.voidspace.org.uk/python/configobj.html#version-4-4-0 until version 4.2.0, nothing catches the eye03:53
=== mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr
=== fog [n=fog@debian/developer/fog] has left #bzr []
smartgpxThe only other instance of "Unable to delete transform temporary directory" in the Launchpad buglist is 137681. This is also a bzr v0.91 report. Might this be a new issue at v.091?04:04
=== bialix [n=chatzill@] has joined #bzr
=== NamNguyen [n=NamNguye@cm38.delta196.maxonline.com.sg] has joined #bzr
=== JWK [n=jwk@ip-159-113.sn2.eutelia.it] has joined #bzr
JWKhello all04:18
JWKI was wondering....where can I find some sort of tutorial on bzrlib internals?04:19
bialixyou mean: how to use bzr from python? or how to hacking bzr in python?04:19
=== tchan [n=tchan@lunar-linux/developer/tchan] has joined #bzr
JWKuse bzr from python, to embed repository fetch/update/commit/branch features in my app04:21
bialixit's a little tutorial you want04:23
bialixthen probably try to read bzrlib/builtins.py source code: it contains implementation for almost all commands04:23
JWKerm...I'd rather not use a working tree, but modify the repository directly04:24
JWKthat doc reports: "Manipulating the Repository Directly => TBD (by someone else who knows what their doing)"04:24
bialixyou cannot commit without working tree04:32
bialixbut you can create new revisions04:32
bialixfor fetch/update/branch -- you need to use branch API04:33
bialixgood example of branch/repo manipulations is probably repo-push plugin04:33
bialix(may be and not so good and slightly outdated, but it works for me)04:34
bialixrepository in the end is just big storage04:34
JWKcan I use branch api without a working tree?04:35
bialixrepository without branch is a but useless thing04:35
bialixJWK: yes, you can04:35
bialixbecause bzr have idea of treless branches04:35
bialixtreeless branch -- branch w/o working tree04:36
JWKok...so repository and branch modules should do04:36
JWKIf I need to add a new revision to a repository, I don't neew a wt either, right?04:38
bialixI'm not sure about commit though, but I think some plugin (e.g. conversion from CVS to bzr) is use direct commit of revisions in repo without creating real wt04:38
bialixif we think about commit as 2-step process: gather changes in tree, and then commit it04:39
JWKthanks...that's the kind of hint I was looking for :-)04:39
bialixthen yes -- second step should not be heavily rely on wt04:39
bialixactually bzrlib/commit.py04:40
bialixcontains logic to create new revisions04:43
JWKit appears that the core part is actually called CommitBuilder and is provided by repository.py itself04:48
jam-laptopbialix, JWK: You might be able to use CommitBuilder directly, but I'm pretty sure bzrlib/commit.py is fairly committed to using something on disk.04:54
jam-laptopThough maybe that is just through the Inventory layer...04:54
jam-laptopcvsps-import goes a different route... but wait04:54
jam-laptopit does use CommitBuilder, IIRC04:54
=== p4tux [n=p4tux@] has joined #bzr
jam-laptopigc: ping05:04
jam-laptopAre you still awake?05:04
bialix/me still awake05:06
bialix/me ?05:07
jam-laptopbialix: I never did respond to your ping yesterday, is there still something you need a response one?05:07
jam-laptopI was wondering if igc was around05:07
bialixI understand05:07
bialixI'm working on fixing bug 12929805:08
ubotuLaunchpad bug 129298 in bzr "Windows standalone installer should create plugins directory" [Low,In progress]  https://launchpad.net/bugs/12929805:08
bialixmy new code is bzr.exe-specific05:09
bialixhave no Idea how to test it. and whether I should test it05:09
tetronwhy is bzr branching so damn slow?  even with the smart server, it takes orders of magnitude longer to checkout a branch with only one (!) revision than it does to download a tarball05:11
keirtetron, we know, it's being fixed05:12
keirtetron, the problem is the current repository format requires two roundtrips per file05:12
tetronthat's gross05:12
keirhopefully 0.92 will have packs (like git packs)05:12
keirtetron, i know, i was shocked when i learned that too.05:12
jam-laptopbialix: you are trying to create a 'plugins' directory somewhere on disk after the installer finishes?05:13
tetronI thought the whole point of the smart server is it asks for "everything from version X to version Y" and the server bundles it all up into one big compressed chunk and sends it all at once..05:13
keirpacks are 50% of rsync speed or sometimes better05:13
tetronthat would be nice05:13
jam-laptopbialix: I would tend to focus on testing the functions you are using do what you want them to, and not worry too much about it happening after the installer runs05:13
keirtetron, sadly no. i actually wrote a plugin to do that aaages ago05:13
tetronkeir: I've had to go through various contortious involving cron jobs that create tarballs to get around bzr checkout slowness05:14
keirtetron, have you tried the newer versions? it's gotten faster lately.05:14
tetroncrap, I'm still using 0.1805:15
tetronI thought I had upgraded on this box05:15
keirnetwork stuff is still slow though :(05:15
tetronwell, it's frustrating, I've been using bzr for a year and performance improvements have always been "right around the corner"05:17
tetronand maybe other stuff has gotten faster, but the checkout speeds are just embarassing, and that's probably driving a lot of people away from bzr05:17
keirtetron, i completely agree05:18
keirtetron, i came to bzr because of usability, launchpad integration, and the commitment to testing05:19
tetronactually, I know for a fact that it's driving people away from bzr, I know one project that switched away from CVS a couple months ago and they went with Hg on the basis of performance05:19
tetronalthough Hg is a pain in the butt to use in other ways that bzr isn't05:20
=== bialix [n=chatzill@] has joined #bzr
tetronwhich is why I prefer bzr05:20
keiri still put bzr being baked at 1 year05:20
keirpacks will help tons05:20
tetronit sounds like it05:21
bialixjam-laptop: actually creating a directory without support inside bzrlib is worth nothing05:21
bialixso I modify default plugins path for bzr.exe05:21
jam-laptopwell, moreso than packs will be getting spiv's streaming work merged into 0.9205:23
jam-laptopGetting it *right* is actually pretty difficult05:23
jam-laptopbialix: well, that is why I say somewhere on disk05:24
jam-laptopsince "inside bzrlib" means that it will be inside the zip file05:24
jam-laptopkeir: the basic "give me everything for these revisions/everything in the ancestry of this one"05:24
jam-laptopThe problem is making sure that you properly get everything05:24
jam-laptopassociated with the fact that when you do "bzr branch" we ignore unreferenced revisions05:24
jam-laptopAnd handling shared repositories05:24
jam-laptopstandalone branches05:24
jam-laptopAnyway, I think Andrew has actually done all the work to get there05:25
jam-laptopand I thought we wanted to land it this week05:25
jam-laptopBut I know he got caught up in some specific details05:25
keirjam-laptop, do you have a sec to help me get the rest of the data structures into this doc: http://bazaar-vcs.org/DataStructures05:25
jam-laptopwhere we were recording 2 things slightly differently05:25
bialixjam-laptop: sorry for my english, but you misunderstand me05:25
keirjam-laptop, i'm trying to make a doc which is 'the data model as exposed by the bzr api'05:26
jam-laptopkeir: how much do you want the "logic" versus what the disk is?05:26
keirjam-laptop, i want the data model05:26
jam-laptopOr I guess what the current api is05:26
keirjam-laptop, but implementation is relevant05:27
keiri don't care about the api at all really05:27
keirthe api is just a way to access / manipulate things in some model of the data in .bzr05:27
keirwhat is that model?05:27
keirit's not clearly and concisely described anywhere05:27
keirhg and git both have very nice docs on this05:27
keirand bzr not having this has been a barrier for me on contributing05:27
bialixthe main idea of that bug is not to have directory 'plugins' somewhere on disk, but IMO have proper support of installing and loading plugins from there05:28
bialixso I change a bit plugins.py: get_default_plugin_path() should return 2 directory for bzr.exe instead of one05:29
jam-laptopkeir: care to point me to one of those references so that I have a better idea of what you are thinking05:29
jam-laptopbialix: you *could* look at "sys.frozen"05:30
keirjam-laptop, git for computer scientists05:30
jam-laptopand then have a test05:30
jam-laptopsuch that if X is True, I get paths A and B05:30
jam-laptopif X is false, I get just path A05:30
jam-laptopAnd then the normal caller will use 'sys.frozen' as X05:30
bialixjam-laptop: I'm indeed look at sys.frozen. I tried to ask you opinion whether I should write a test for this complicated bzr.exe-only stuff05:30
keirfor hg: http://www.selenic.com/mercurial/wiki/index.cgi/Design05:31
bialixjam-laptop: I'm feeling unhappy to write 20-100 lines test for 2-lines change05:31
jam-laptopbialix: I understand, but as a maintainer it means you don't have to worry about me breaking it in the future05:32
jam-laptopI don't think it has to be a huge amount of testing05:32
keirjam-laptop, i want to start with a very concise overview of the data model (which should be detailed enough that I could write a SQL schema for it), then have a couple examples of real dat05:32
jam-laptopkeir: do you mind if I write up an overview in ReST on that same page, and then ask you to fill it in?05:33
keirjam-laptop, not at all05:33
jam-laptopif it is in ReST, then we will likely pull it into the core docs05:33
keirjam-laptop, i plan on making it ReST anyway05:33
jam-laptoprather than in Wiki05:33
keirjam-laptop, and putting it in core docs05:33
bialixjam-laptop: actually about this special test: it's never will be run on PQM, so I can't use it for automatic regression testing, otherwise I need very complicated fixture for test, and selftest anyway does not pass on win32 -- and this makes me unhappy about testing05:33
keirjam-laptop, i wanted to show people what i was working on05:33
bialixkeir: you could use ReST in our wiki05:34
keirbialix, oh, news to me!05:34
jam-laptopbialix: you can write a test that function "get_plugin_paths(is_frozen)" returns different values when 'is_frozen' is true versus fals05:34
keirjam-laptop, just add the rough content, i'll deal with making it nice and expanding05:34
bialixjust add at the start of document line #! format rst05:34
jam-laptopkeir: you start with a "#FORMAT rst"05:34
jam-laptopbut I'll do that05:34
keirjam-laptop, should we bother with the wiki? i'd rather put it in core docs05:35
keirjam-laptop, and link prominently to it in HACKING05:36
jam-laptopkeir: well, it is easier to collaborate between you and I on the Wiki05:36
keirjam-laptop, sure05:36
jam-laptopand then when we get it worked out05:36
jam-laptopmove it05:36
keirjam-laptop, great05:36
bialixkeir, err sorry, jam is right05:36
bialixhere example: http://bazaar-vcs.org/Talks?action=raw05:36
bialix/me brain damaged by shebang05:37
keirtetron, what parts of hg do you dislike?05:42
tetronkeir: the thing that annoys me the most is when doing a merge and there are conflicts, hg insists on popping up a merge window for every conflict, in order, with no way to go back or forward or just tell it to shut up and mark the files as conflicted like every other reasonable VCS05:44
keirtetron, oh, that would be annoying05:45
bialixkeir: iiuc it play very terrible when you're on windows, because hg need some diff3/merge3 program05:46
tetronyup, it's obnoxious like that05:47
tetronit has a concept of multiple "heads" in a branch, which is usually just used for merging but it's possible to have them be named and distinct, which can cause chaos if somehow you branch off from someone and change the name, and then try to merge back later05:48
tetronthe hg logs are flat, they don't show branch merges as distinct changesets the way bzr does05:49
=== BasicOSX [n=BasicOSX@errant.real-time.com] has joined #bzr
keiris there a way to specify what bzr to run when doing bzr+ssh? the default path bzr+ssh uses gets the wrong one on my machine05:51
jam-laptopkeir: try looking at it05:51
jam-laptopI don't have a lot more time right now, but it should give you a start05:51
bialixjam-laptop: thanks for suggestion. I think it's time to a some refactoring in plugins.py05:51
jam-laptopkeir: The env var BZR_REMOTE_PATH05:51
keirjam-laptop, aah, cool.05:51
keirjam-laptop, but it's different for every host...05:51
jam-laptopkeir: I think Aaron has a patch pending to allow you to set it in ~/.bazaar/locations.conf05:51
jam-laptopI'm not sure if that has been merged or not05:51
bialixkeir, keir, Aaron's path is already merged05:53
keirjam-laptop, this is going in a different direction than what i want. i literally want a bulleted-list style description such that i could go and write a SQL schema05:53
keirjam-laptop, i'll hack on it05:53
=== abentley [n=abentley@bas2-toronto02-1279462552.dsl.bell.ca] has joined #bzr
keirhi aaron06:07
keirdid your patch to allow setting BZR_REMOTE_PATH per-host in locations.conf get merged?06:07
keirabentley, nevermind bialix answered but i missed his response.06:19
=== bigdo2 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr
keirin an InventoryEntry, what type is a 'parent_id'?06:23
keiris it a Revision ID?06:23
keiror a (fileid, revisionid) tuple? (aka another inventoryentry)06:24
=== p4tux [n=p4tux@] has joined #bzr
keirand 'name' is just filename relative to the inventory root?06:25
luksto the parent06:25
keirwhat is the type of 'parent'?06:25
luksehm, parent is the parent id, no?06:26
lukswhich is a fileid06:26
keirso why is name even necessary?06:26
luksto construct the full path06:26
keirso this 'name' entry is there for the strong renaming support?06:27
lukse.g. (1, 'foo', 0), (2, 'bar', 1) -> 'foo/bzr'06:27
keirand generally the 'name' field will be exactly the same 'myfile.txt' for ever rev, if it's not renamed?06:27
luksyes, but fileid is used in all internal operations06:27
luksif you rename a file, it will still have the same inventory entry06:28
luksheh, I just noticed I typed 'foo/bzr' instead of 'foo/bar' above :)06:28
keirin your above example you had (fileid, name, parent_file_id), right?06:29
keirok. and in this case, parent is strictly relating to _directories_ and not revision history?06:30
keirdamn. calling it parent_id is madly confusing06:31
lukswell, calling it parent_id is very usual in databases06:31
keirbecause in revisions the 'parents' are relating to revisions06:31
luksto make a tree in flat DB06:31
keirthe SHA1 hash is a hash of the fulltext of that particular fileid,rev?06:33
keiror is it a hash of the delta?06:33
luksof the fulltext06:34
luksbut generally, inventory can't know much about deltas06:35
keirwhat is in Revision.parent_sha1s06:39
=== mvo_ [n=egon@p54A65DA6.dip.t-dialin.net] has joined #bzr
keirobviously they are sha1's, but it's not clear what the 'sha1' of a parent is06:42
keiris it a sha1 of the textual representation of the parent revision?06:42
luksnot sure about that06:42
jam-laptopkeir: I'm pretty sure that is unused at the moment06:43
keirjam-laptop, yes, i just noticed that06:43
jam-laptopAt 1 point references were (revision_id, sha1) tuples06:43
jam-laptopBut that was a long time ags06:43
keirjam-laptop, refresh that page and see revision and inventory section06:43
keirjam-laptop, i am specifically not wanting paragraph-style descriptions because it is harder to digest06:44
keirso if you do bzr diff -r1:206:45
keirhow is the inventory used?06:45
keiris the inventory linerally scanned to find (fileid,revid) tuples with the rigth fileid?06:45
luksit takes the inventory for r1 and r2 and checks the differences06:45
=== poolfool [n=poolfool@techsat21.itnes.com] has joined #bzr
luksthen it takes fulltexts for r1 and r2 or each modified file, and prints the diff06:46
keirso this is fast if it's sorted on revid06:46
lukskeir: there is only one revision of a file in inventory06:46
luksso there is no need to find fileid,revid tuples06:46
keiri'm confused then06:47
luksinventory is a versioned file06:47
keirso there's one inventory per file?06:47
luksone per repository06:47
keirif an inventory is a big list of (fileid,revid,metadata)06:47
luksbut the content changes for every revision06:47
keirthen for one rev, there will be many fileid's06:48
keirso if you sort by rev, you get all your relevant fileids in one spot06:48
luksit's more a dict fileid->metadata06:48
keirso you can go fileid-> complete revgraph for that file06:48
luksinventory is a snapshot of the tree at given revision06:49
luksthere is always only one version of each entry in it (the most recent version)06:49
keirwait. so there's only one inventory per revision?06:49
luksnot sure what do you mean by 'per revision'06:50
keirif i do a commit, is there a new, standalone inventory generated06:50
keirand there is an inventory per-file?06:50
keira new inventory file per rev?06:51
luksit's not really a file06:51
luksthe inventory knit contains all the inventories06:51
keirso a repository has many inventories?06:51
luksyou confuse me :)06:52
keirbzr confuses me!06:52
luksthink of it like of a regular file in your branch06:52
luksif you commit, bzr will generate a new snapshow of inventory and store it in the inventory knit file06:52
keirso there's a 1-1 mapping revision to inventory06:52
=== dpm [n=dpm@p54A13505.dip0.t-ipconnect.de] has joined #bzr
luksso there is only one inventory knit per repository06:53
luksbut the knit contains also historical inventories06:53
lukskeir: basically yes06:53
keiri was confused about that06:54
keirwhat i didn't understand is why bother storing the revision for each fileid in an inventory06:54
keirshouldn't an inventory have a _single_ revision ID and then every file inside has an implied revision id from the inventory?06:54
keirthe description i've been hearing is that an inventory is a list of (fileid, revid, metadata)06:55
keirrepeated per file changed in this revision06:55
luksyou usually modify only some files in a commit06:55
keiri see06:55
luksso most of the inventory entries wont even change06:55
keirso all that delta info gets duped?06:56
keirper rev?06:56
keirif it isn't changed?06:56
keiri.e. the (fileid, revid, metadata) in an inventory for rev 10 where that file wasn't changed since rev 5, will contain the same (fileid,revid,metadata) as in rev 5?06:56
luksbut this all is stored in a knit, so the data are not duplicated on the disk06:57
keirwhy bother listing unchanged files?06:57
keirah, ok06:57
keirso a revision isn't really a snapshot of a tree06:59
keiran inventory is06:59
luksI think inventory is a 'snapshot of a tree' by definition07:00
jam-laptopkeir: It might help to realize that we *logically* think of things in "fulltext" form. We happen to store a lot of them as deltas07:03
jam-laptopbut that is handled at a lower level07:03
jam-laptop(It depends on the Repository format)07:03
jam-laptopWe will probably undergo another change in the near future07:04
jam-laptopto break an inventory into many separate files on disk07:04
jam-laptopfor performance reasons07:04
jam-laptopbut you can still think of it as logically one big manifest07:04
keiri thought the inventories were going to get packed?07:04
=== asak [n=alexis@201-27-62-87.dsl.telesp.net.br] has joined #bzr
lukspacks are just masked knits :)07:04
jam-laptop"packed" just means storing in a single delta-compressed file07:05
jam-laptoplogically we still work in terms of a group07:05
jam-laptopAnd when they are in packs07:05
jam-laptopit just means they are in several distinct chunks inside the pack07:05
jam-laptoprather than one big hunk07:05
keirso right now 1) a single file has multiple inventories 2) the inventories are not spatially coherent?07:06
jam-laptopkeir: yes, we are moving to storing all the data for one or more revisions in one big file (a pack)07:06
jam-laptopkeir: I'm not sure what you mean by "single file". But right now:07:06
jam-laptopEvery revision has a unique Inventory07:06
jam-laptopThe revision maps the exact text for every file in the tree07:06
jam-laptopThe Inventory maps the exact text for every file in the tree.07:07
jam-laptopAt the moment, that Inventory is serialized as one big text07:07
jam-laptopand it is stored delta compressed just like we store file texts07:07
jam-laptopAnd we have 1 file for every file object and Inventory and Revision07:07
jam-laptopIn the future07:07
jam-laptopwe will be switching from 1 file per object07:07
jam-laptopto having file texts stored next to inventories next to revision texts07:08
jam-laptopWe are calling that a "pack"07:08
jam-laptopWe are *also* moving to split up the 1-big inventory text into multiple smaller texts07:08
keirso what's in a knit? a series of deltas?07:08
jam-laptopkeir: deltas + occasional fulltext snapshots07:08
keirthat seems sensible.07:08
jam-laptopso if you have 10,000 entries you don't have to reconstruct all of them07:08
jam-laptopto get the last one07:09
jam-laptopa Knit is similar to Hg's revlog07:09
jam-laptopexcept we delta based on ancestry07:09
keirand you're going to change that by 'transposing' the current per-file storage so that related diffs occur coherently in a single file?07:09
jam-laptoprather than just the last node in the file07:09
jam-laptopkeir: correct07:09
jam-laptopThere are other things we might do (change what kind of diff algorithm we use, etc, etc)07:09
jam-laptopBut that is at a disk storage layer, which is hidden underneath the Repository abstraction07:10
keiryes. i suspect switching to libxdiff or xdelta will be a big space win07:10
keirand a branch is a big list of revisions?07:15
keircorresponding to a linear thread of development?07:15
luksbranch is a pointer to the 'head' revision07:16
luksother info is derived from the history graph07:16
luksand it's linearized by going through the left-most parents07:17
=== n2diy [n=darryl@wlk-barre-208-103-148-45.dynamic-dialup.coretel.net] has joined #bzr
fullermdbzr is a magic cauldron; you put your data in, let it sit for 4-6 hours, baste occasionally.  Serves 3-10000.07:28
keirwhere are weaves described?07:29
keirfound it07:29
keirso how are inventories stored now so that they don't list duplicate (fileid,revidY) for files that didn't change in revidX?07:31
luksthe same way usuall versioned files are stored - "19:08 < jam-laptop> keir: deltas + occasional fulltext snapshots"07:36
keiran inventory is not text; so it is serialized then diffed'?07:37
luksit's xml07:37
=== keir gets an icky feeling
=== bialix [i=chatzill@] has joined #bzr
keirthat really is unfortunate07:40
=== Vernius [n=tomger@p508AD68E.dip.t-dialin.net] has joined #bzr
keirso packs are the same? inventories are diff'd XML?07:46
=== pbor [n=urk@host102-21-dynamic.60-82-r.retail.telecomitalia.it] has joined #bzr
=== bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr
keirso right now, to generate a diff 1) find revision id A and B 2) find corresponding inventories 3) get list of files that differ 4) hit knits for the texts and do a diff07:50
keirso .bzr is really just revisions, inventories, and texts?08:02
=== cbarrett [n=cbarrett@adium/cbarrett] has joined #bzr
keirignoring branches08:02
fullermdAnd whipped cream.  Don't forget the whipped cream.08:02
fullermdIgnoring the WT too.  You're talking about .bzr/repository/ it seems.08:03
cbarrettmneptok: nice regurg impression08:03
keirso a WT is just the checked out files and a pointer to the branch?08:03
=== fog [n=fog@debian/developer/fog] has joined #bzr
fullermdStatus of the checked out files.  What revision it's on.  Pending merges.  Probably other bits&pieces...08:08
=== danigm [n=danigm@] has joined #bzr
=== JWK [n=jwk@ip-159-113.sn2.eutelia.it] has left #bzr []
=== orospakr [n=orospakr@] has joined #bzr
=== poolfool [n=poolfool@techsat21.itnes.com] has left #bzr []
danigmhi, I'm learning bzr, I'll make some projects, and I'm considering svn, bzr, and other vcs. But I don't understand bzr. When I have a branch in a server, I make a branch to my pc, and work on it, and then merge and push it. It's a correct use of that?08:13
Pengdanigm: Yes?08:19
Pengdanigm: That's the same as all over the other distributed VCSes.08:20
keirdanigm, you work (hack/commit/hack/commit/hack/...) then merge (gets new changes from server that happened inbetween) then push08:20
PengYou won't necessarily need to merge.08:20
fullermdYes, it's _a_ correct use.  The problem (and the great thing) is that DVCS's support a large number of possible workflows, so the 'correct' one is pretty situation-dependant.08:21
danigmif you don't merge, you can't push08:21
Pengdanigm: If there are no new changes on the server, you don't need to merge.08:21
cbarrettusually it's called a "pull" to get new changes from the server.08:21
PengThat too.08:21
cbarretta merge is an operation to decrease the number of heads, where a head is a revision with no children.08:22
danigmI only use svn before, and you make commit in server directly, it's possible with bzr?08:22
Pengdanigm: Yes. But why?08:22
danigmI don't know08:22
cbarrettdanigm: why do you want to use bzr?08:23
danigmcbarrett: I'll make a game with some people, and I need a vcs08:23
danigmI'm considering put the project in launchpad08:24
=== duckx [n=Duck@tox.dyndns.org] has joined #bzr
=== Ohrmann [n=Ohrmann@p57AB5E77.dip.t-dialin.net] has joined #bzr
OhrmannHello i need help with a freshly installed Windows version of bzr? Can anyone help?08:30
james_wOhrmann: what's the problem? I haven't used Windows bzr before, but knowing the problem is a start.08:36
OhrmannOk i used the installer and now i try to "bzr init" and i get always an error "bzr: ERROR: Unknown branch format: 'Bazaar-NG meta directory, format 1\r\n'"08:37
OhrmannOh no im an idiot. I tried to use bzr in a subdirectory of an archive.08:39
OhrmannSorry for the nois08:42
=== EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #bzr
=== BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr
=== Demitar [n=demitar@] has joined #bzr
=== jelmer is now known as jelmer_
=== michelp [n=michelp@] has joined #bzr
=== jelmer_ is now known as jelmer
=== deadwill [n=deadwill@146037.fln.virtua.com.br] has joined #bzr
=== deadwill is now known as xxxxx1
=== BjornT [n=bjorn@canonical/launchpad/BjornT] has joined #bzr
=== joejaxx [i=joejaxx@fluxbuntu/founder/joejaxx] has joined #bzr
=== thumper [n=tim@] has joined #bzr
=== jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr
=== thumper [n=tim@canonical/launchpad/thumper] has joined #bzr
=== Keybuk [n=scott@wing-commander.netsplit.com] has joined #bzr
Keybuka question about cherry-picking ... I'm doing merge -r X-1...X, which gives me a conflict in ChangeLog (shock)10:59
Keybukthe odd thing is that the conflict includes far more data from the ChangeLog than what was in that single commit10:59
mwhudsoni wonder what bzr uses for the merge base in that situation11:00
Keybukam I cherry-picking the right way?11:00
luksI usually get better results for such situations (especially changelogs) with the weave merge11:00
mwhudsonmaybe things might become a little more obvious if you passed --show-base to merge11:01
Keybukmwhudson: example?11:01
KeybukI'm doing the pretty standard use-case of cherry picking commits from trunk onto a stable branch to make a new stable release11:02
Keybukso say I want to take revision 726 from trunk, how would I do that?11:04
Keybukluks: weave made an even worse job of it11:05
Keybukit merged the entire changelog from trunk into the branch11:05
Keybukwithout even marking a conflict11:06
=== Alien_Freak [n=sam@adsl-69-209-192-74.dsl.chcgil.ameritech.net] has joined #bzr
Alien_Freakhey guys11:09
=== BjornT_ [n=bjorn@ip-213-190-55-148.static.b4net.lt] has joined #bzr
=== bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr
keirso in the .tix, it seems (fileid,revid) entries have two parents. one is the text delta parent (i think?) and the other is the history parents. is this right?11:19
=== CardinalFang [n=c@user-0c6ti96.cable.mindspring.com] has joined #bzr
keirand no delta parent implies a fulltext11:22
keirand the same for .iix files (inventory index)11:22
CardinalFangUgh.  Have developers tried the web site's download instructions lately?11:23
=== CardinalFang runs $ time bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev
keirCardinalFang, we're working on it11:23
keirpack repos are coming in 0.9211:24
CardinalFangI know speed-ups are on the map.  Maybe the native non-HTTP server is better so that newbies aren't scared off.11:25
keirnot much, yet11:26
keirsomeone else is hacking on that11:26
CardinalFangkeir, I'm not sure you understood.  I'm saying that "bzr://" would be better than "http://" if you're trying to make a good first impression.11:37
=== mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr
CardinalFangI'm new, and I'm trying to test whether bzr will be useful for my new projects.  By Ubuntu box comes with "bzr", but I know it's under rapid development, so I want to see if the recent code is good enough right now.  Getting its own source took 18 minutes.11:40
keirCardinalFang, i agree, but it's not that much faster than http yet!11:41
fullermdWell.  [bzr+] http would work too...11:47
=== abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr
james_wKeybuk: it's hard to know what the problem is without seeing the revisions and the outcome.11:53
james_wKeybuk: however what you have said is the normal way to approch this.11:53
james_wif the merge includes things that are not present with diff with the same arguments then it may indicate a bug, I'm not sure.11:54
Keybuk$ bzr branch -r 665 http://bazaar.launchpad.net/~keybuk/upstart/main upstart11:55
Keybuk$ cd upstart11:55
Keybuk$ bzr merge -r 725..726 http://bazaar.launchpad.net/~keybuk/upstart/main11:55
Keybukcompare "bzr diff ChangeLog" to "bzr diff -r 725..726 http://..."11:56
Keybukthe conflict includes the *entire* ChangeLog text on the main branch11:56
Keybukrather than what was actually in that commit11:56

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