=== AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr === fog [n=fog@debian/developer/fog] has left #bzr [] === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has left #bzr [] === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr === BasicOSX [n=BasicOSX@216-250-187-201.static.iphouse.net] has joined #bzr === bitmonk [n=justizin@adsl-76-212-10-56.dsl.pltn13.sbcglobal.net] has joined #bzr === cprov-out is now known as cprov === jml_ [n=jml@203-113-250-169-static.TAS.netspace.net.au] has joined #bzr === kiko-afk is now known as kiko [01:26] poolie: call ? === jml_ is now known as jml [02:20] New bug: #148787 in bzr "rpm packages out of date" [Medium,Confirmed] https://launchpad.net/bugs/148787 [02:27] spiv, hi? === asak_ [n=alexis@201-13-29-191.dsl.telesp.net.br] has joined #bzr === mw is now known as mw|out [02:44] fullermd: If you start with "branch5/branch6" then switch to "dirstate/dirstate-tags", you have only yourself to blame for the resulting confusion. === bratsche [n=cody@adsl-68-94-60-43.dsl.rcsntx.swbell.net] has joined #bzr === orospakr [n=orospakr@bas4-ottawa23-1167863898.dsl.bell.ca] has joined #bzr === pete__c [n=pete@015-850-358.area5.spcsdns.net] has joined #bzr [03:18] poolie: hi === orospakr [n=orospakr@CPE001a70d1de84-CM0019474a8676.cpe.net.cable.rogers.com] has joined #bzr [03:41] spiv, i'm going to get some early lunch, can we talk after that? [03:43] Ok. [04:09] mmm food === jml [n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net] has joined #bzr === bratsche_ [n=cody@adsl-68-94-63-182.dsl.rcsntx.swbell.net] has joined #bzr === Verterok [n=ggonzale@75-108-235-201.fibertel.com.ar] has joined #bzr === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === lifeless hates on evo [04:40] poolie: ping re reviews === cprov is now known as cprov-Zzz [04:47] lifeless: If you find a good replacement, let me know :-) [04:48] abadger1999: I hear telnet is [04:59] abadger1999: wat clay, a reed, and knowledge of cuneiform is far superior solution than Evolution [04:59] *wet [05:00] hah! [05:00] mneptok: its funny cause its true [05:00] I switched to t-bird from evo a month ago and was somewhat satisfied until the gpg plugin started causing it to hang. [05:00] lifeless: "funny" in that "i really chuckled as i tasted the gun oil" way [05:01] lifeless, i'm reviewing your code === bitmonk_ [n=justizin@76.212.10.56] has joined #bzr [05:01] mneptok: you're heading for quotes page again [05:01] I may have to try sylpheed-claws next. [05:01] poolie: thank you! [05:02] poolie: sypy is on tonight btw, I plan to head along === bratsche [n=cody@adsl-68-94-25-44.dsl.rcsntx.swbell.net] has joined #bzr [05:06] abadger1999: Claws' predeliciton for the "hey! welcome to your new day! remember that mail you imported yesterday? i deleted that for you!" was a bit annoying [05:07] poolie: I've sent 3 new up today I think [05:08] poolie: I'm going for lunch, if theres something you want to ask me about, ring me please [05:09] hello mneptok [05:09] nice to see you [05:09] i wonder what claws is like these days [05:10] really i just want a mutt that can search quickly, has a bit of mouse support, and doesn't spaz out when its connection drops [05:11] poolie: 'allo sahib :) [05:11] poolie: kind of like an offline gmail then? [05:12] poolie: Claws' performance vis-a-vis speed is excellent. performance vis-a-vis data integrity ... not so much. in my experience. [05:12] jml, gmail is pretty close to doing it for me [05:13] better keyboard support would be nice [05:13] Greasemonkey? [05:13] builtin gpg handling would be good too, though i realize some hacks are possible with encrypting the clipboard etc [05:13] poolie: my main gripe is that it needs internet and "open next email" takes too long (because of internet) [05:14] mneptok, you know you could probably get in trouble making that proposition to some people [05:14] :) [05:14] poolie: I've been using some firefox extension to add gpg support to gmail. it's not bad. [05:14] after using gmail for a while i just switched to evo to see how it was [05:15] too many crashes [05:15] poolie: only if on follow-through my techique is sub-par ;) [05:15] hello radix [05:15] hi poolie :-) [05:21] back [05:22] evo would be really good if its developers used it [05:24] if it's developers used it, they'd all kill themselves. [05:29] nah [05:29] but they would fix it === BasicOSX [n=BasicOSX@216-250-187-201.static.iphouse.net] has joined #bzr [05:41] hmm what to do [05:44] spiv, hi? [05:47] poolie: hello [05:48] call? [05:48] poolie: want to call? [05:48] snap [05:54] lifeless: i find it unlikely Microsoft employees would actually use Evolution [05:54] *bah dum tish* === thumper [n=tim@125-236-193-95.adsl.xtra.co.nz] has joined #bzr [05:54] mneptok: bitchy [05:54] I like it === jeremyb [n=jeremy@unaffiliated/jeremyb] has joined #bzr [06:04] :) [06:19] poolie: replied to your review [06:27] >Would you prefer a[:] = [] ? [06:27] well [06:28] when i first read it, i didn't see the [:] and wondered "why on earth is he deleting it"? [06:28] then about 10s later i saw it [06:28] I find the del clearer [06:28] because [:] list replacement is IME rarely used [06:28] and the point here is to preserve the instance of the list [06:29] yes, i understand that [06:29] I wouldn't want someone to do a = [] as a 'cleanup' [06:29] exactly [06:30] maybe you should add a comment explaining you need to keep the instance? [06:32] sure [06:32] so i find it a bit strange, though at the same time straightforward, that the meaning of 'del a' is utterly different from 'del a[...] ' [06:32] but, that's neither here nor there [06:33] your response is fine with me, anyhow [06:33] thanks! 1 down, X to go :) [06:38] oh, abadger1999 is toshio [06:38] i presume [06:39] Yep. [06:40] Looking at the Fedora Packaging bug? [06:46] speaking of packaging, I've still got this glitch === orospakr [n=orospakr@bas4-ottawa23-1088827158.dsl.bell.ca] has joined #bzr === BasicOSX [n=BasicOSX@216-250-187-201.static.iphouse.net] has joined #bzr === keir [n=keir@76-10-151-153.dsl.teksavvy.com] has joined #bzr [06:55] abentley, ping [06:56] pong [06:59] hi keir [07:00] keir: I've been poking a bit at your code. I'm concerned that the split between key names and data means the locality of reference win will be entirely nullified with todays access pattern and API's [07:00] keir: also, have you done any performance tests with your code? === bitmonk [n=justizin@adsl-76-212-10-56.dsl.pltn13.sbcglobal.net] has joined #bzr [07:09] abadger1999, yes, but in particular this was the first time i remember seeing your name in mail, or at least the first time i made the connection [07:10] it also made me smile because my partner is a tiki enthusiast [07:10] Ah :-) [07:17] poolie: do I get any other reviews ? :) [07:18] i've done all but one of them [07:18] by BB's count [07:18] oh hmm [07:18] i can do that one after matthew's, if you like === BasicOSX [n=BasicOSX@216-250-187-201.static.iphouse.net] has joined #bzr [07:26] poolie: please do [07:31] lifeless, no, i haven't done any perf testing yet [07:32] abentley, if you're going to make a trac-killer, go for full distributed [07:32] abentley, and i feel rather strongly that the killer feature of trac is the pervasive wiki [07:32] Well, it sounds like you need to write your own. [07:32] abentley, if i could have local editing of the wiki along with the trac wiki integration for tickets and such... sweeet [07:33] abentley, so you're not going to try distributed? [07:33] I think wiki integration is killer; I think trac's including the wiki is whack [07:33] If it's successful, it might expand that way. [07:33] But distributed is really complicated. [07:33] better to work closely with a wiki that is just a great wiki, than write a new one [07:34] abentley: btw, I love the name [07:34] And I don't need that right now. [07:35] i was thinking something that used ReST [07:35] lightweight [07:35] actually, i like the name, but i think it is a bad idea [07:35] because it is not googleable [07:35] the new project 'review board' for example. WORST NAME EVER [07:35] try finding that one! [07:36] lifeless: Thanks. I saw it there, and I figured I had to use it, but it's probably just a working title. [07:36] lifeless, if we toss the split between data / key, then we can't topo sort [07:36] I think it's amusing that "Trac" is actually a real word backwards. [07:37] keir: I'm pretty sure you are wrong [07:38] lifeless, then how are you going to find keys? [07:38] lifeless, you can't build a btree on keys anymore because they're not sorted [07:38] well [07:38] so you have to build a btree of keys to find their position in the topo sort... then you're back where we are now [07:38] so the split between keys and data just groups the data (small) away from the keys (large), but we need th ekeys to answer every query, so we access large data anyhow [07:38] I raised this in my first design review on the list [07:39] right [07:39] keir: Making a distributed wiki is one thing. That's basically just using Bazaar as a wiki backend. [07:39] another way of getting grouping is to keep the keys and data together, and to index on topological index [07:39] But a distributed bug tracker with correct merging is a lot more complicated. [07:40] (that is, topo sort the names presentin the index, assign them in the result order numbers from 0->N-1, and order them that way) [07:40] lifeless, then you have another entire copy of the keys, no? [07:40] no [07:40] not at this point in the sketch anyhow :) [07:40] i give you a key. how do you find the data in the 'btree' say? [07:41] theres no tree in this thought experiment [07:41] ok [07:41] just linear grouping based on topo ordering [07:41] so how do you do better than linear scan? [07:41] finding an arbitrary key by name is linear [07:41] ok [07:41] so to beat linear [07:41] you have to build an index on the keys [07:41] not necessarily [07:41] to find their topo index [07:41] it depends on what operations are common [07:41] see, this pattern: [07:42] find key X [07:42] find key[X.parent] [07:42] etc [07:42] right [07:42] but if you want to do better than linear for 1st step [07:42] are amortised linear(index size) for the first op, plus constant time for every additional step [07:42] you're sunk because you need to build an index on the keys... [07:43] there are two reasons to have fast access to an individual key [07:44] one is direct access to it [07:44] the second is to make the miss-case fast(because its as slow as the worst case key lookup) [07:44] its possible to address the second reason without addressing the first via bloom filters, if we want to. [07:44] bloom filters are very fast [07:45] now, I suspect we do need reasonably fast direct access [07:45] and I'm still mulling this [07:45] i don't see any way to have fast direct access without an index on the keys [07:45] which implies at least 1 copy of the keys sorted by keys [07:45] I suspect we have 2-3 versions of indices to get a really really good one [07:46] well, copy of the keys is misleading because you can index on much less than the sum of the keys [07:46] via e.g. hash'es, tries, [07:47] sure, if we go the hash route [07:47] you can probe in a hash table to get a list of byte offsets the key may be at [07:47] if there is nothing there, its not in the index, if there is, then follow it to see if its the one you want [07:47] no key data, and a variable length hash allows this to scale with index size [07:47] true [07:48] so hash to list of offsets? [07:48] don't need secure hashes here - the real data is always present, and we want it, so follow it to handle hash collisions [07:48] sounds reasonable [07:48] anyhow, project wise - [07:48] i can do that [07:48] I have 3 weeks more or less before UDS [07:48] but we freeze well before that [07:48] so here is what I'm thinking... [07:49] lifeless, ok, all your patches that i can see are now merged [07:49] i mean, reviewed [07:50] I toss a trivial 4K-fan-out prefix on the current index and do page-size bisection. This is for 0.92, and is better-but-not-ideal. We freeze the disk format with this, and continue working on your code - getting the design profiled and so on. [07:50] lifeless, sounds sensible [07:50] keir: does this make sense to you? It means there is no insane rush to get your index *right*, but its still in the pipeline. [07:50] lifeless, yes. if adding topo sorting isn't too hard, i'll do that after. [07:50] packs will be getting reved post 0.92 anyhow as the newer delta logic gets slotted in, so theres plenty of window to drop a new index layer in. === bitmonk [n=justizin@adsl-76-212-10-56.dsl.pltn13.sbcglobal.net] has joined #bzr [07:52] ok, i have to run [07:52] lifeless, what if anything did you decide about the gsoc summit? [07:52] i may hop on over the weekend === g0ph3r [n=g0ph3r@p57A09E16.dip0.t-ipconnect.de] has joined #bzr [07:52] keir: ok, bye! [07:53] poolie: hot damn I entirely forgot to look that up [07:53] you wouldn't happen to know where the announcement stuff is? I haven't been emailed about it so have no links [07:54] uh i think it's next weekend so probably not [07:54] http://groups.google.com/group/google-summer-of-code-mentors-list/browse_thread/thread/7632570e13d7813e/e69899cd12d7c7ad#e69899cd12d7c7ad [07:54] iow, in two days time [07:54] "can i borrow your jet?" [07:55] meep [07:56] guess not lol [07:56] hmm, bb says its reviewed, but I don't see mail about it [07:56] the fetch patch === BasicOSX [n=BasicOSX@216-250-187-201.static.iphouse.net] has joined #bzr [07:58] after i finish vila's patch i'm going to take a break as i have calls tonight [07:59] then will submit my patch [07:59] ok [07:59] please let them know that the packs patch is very small now, with these things reviewed [08:00] and I'll be doing the index thing as the next priority [08:00] so Monday I hope to be sending in the last patch to remove the packs branch [08:00] that is to merge the entire thing [08:02] lifeless, what is the real difference in intention between tests/blackbox and tests/commands? [08:02] the docstring is not very enlightening [08:02] search me, let me look [08:03] vila seems to have created this [08:03] poolie: commands/ invokes the objects directly [08:03] poolie: cmd = cmd_cat() [08:03] cmd.run(self.get_url('branch/foo')) [08:04] self.assertEquals(1, len(self.connections)) [08:04] self.assertEquals('foo', self.outf.getvalue()) === Zindar [n=erik@h188n1fls12o803.telia.com] has joined #bzr [08:04] so it is avoiding the run_bzr* infrastructure, its a lower level test. [08:04] I think this is quite reasonable but the docstring is as you say unclear [08:04] yes that does seem to be it === Zindar [n=erik@h188n1fls12o803.telia.com] has joined #bzr [08:05] to me, that layer seems so thin that it is not worth separately testing with and without it [08:06] I don't like the idea of duplicate tests with and without it [08:06] I would quite like to have tests of that layer and all the others tests written without it; personally. [08:07] anyhow, I'm out for the day; got lots done === AfC [n=andrew@218.185.75.132] has joined #bzr [08:14] lifeless, any debs yet? [08:14] tests of the argument parsing and everything else done without parsing? [08:14] that would be ok with me [08:14] i think [08:15] New bug: #148857 in bzr "add should not show count of ignored files" [Low,Confirmed] https://launchpad.net/bugs/148857 === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr [08:37] poolie: yes, just now in fact. [08:37] poolie: without sid, its failing to build for me [08:59] poolie, lifeless : regarding tests/commands, its origin in rev 2485.8.3 in bzr.dev, back in London Sprint, robert told me to separate the tests I was written in test_init (aimed at testing the init command) into a new hierarchy [09:00] and also to create a dedicated transport (based on ftp) to avoid testing against all transports [09:01] the distinction between blackbox (testing the API) and tests/commands for the internal behavior was a bit blurry though :-/ [09:02] I think the idea was the connection sharing problem was seen as internal to the commands and not worth blackboxed as users shouldn't be aware of such detail === mkanat [n=mkanat@c-71-202-202-106.hsd1.ca.comcast.net] has joined #bzr [09:09] Is there any way to get a log for all of the items in a directory? [09:09] Particularly from a repo with no working tree. [09:10] vila: well I advised that when you asked a specific quest [09:11] question [09:11] lifeless: I'm not throwing stones ;) [09:11] :) [09:11] I'm off to sypy [09:11] just explaining the history to help find the right answer [09:12] which I still don't have unfortunately :-/ === vila leaves for a couple of hours, bbl [09:12] ciao [09:15] last thought and I'm really gone, I think there is value in testing at that level ,but truth is, the tests I have written could be blackbox ones... === mvo [n=egon@p54A67EA1.dip.t-dialin.net] has joined #bzr === acuster [n=acuster@89.7.90.220] has joined #bzr [09:22] Hey all, I just imported a large project from svn into bzr. It took many hours and all my memory but eventually finished---very cool. [09:22] However, bzr log lists a bunch of files under a "removed:" header [09:23] the same thing happened when I did a bzr init; bzr add on a fresh svn checkout [09:24] can anyone explain how bzr is handling those files? === allenap [n=allenap@87-194-166-60.bethere.co.uk] has joined #bzr === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr === mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr [09:52] after 'bzr revert' is 'bzr st' supposed to have a 'removed:' section? [09:59] acuster, no, it should normally not [09:59] thanks [10:00] does bzr make errors building a repository due to file name issues, file content issues or layouts? === jrydberg__ [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr [10:17] can you explain the question more? [10:22] https://bugs.launchpad.net/bzr/+bug/148884 [10:22] Launchpad bug 148884 in bzr "'bzr add' and 'bzrsvn branch' work but have st with a 'removed:' section" [Undecided,New] [10:22] would bzr have issues on files in different encodings? [10:24] looking [10:24] thanks [10:25] that is strange [10:25] bzr handles filenames as unicode [10:26] so it does have trouble if there are names that are not valid in your machine's encoding === herzel104 [i=herzel@gateway/tor/x-fad769a1e8f6340c] has joined #bzr [10:26] the file names look ok, I was thinking in terms of contents [10:27] generally no, though there are some more things we'd like to do to accomodate people with varying encodings within their tree [10:27] that is, with files whose encoding doesn't match your locale's encoding [10:27] blackpad:/soft/BZR/geotools/trunk> file gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfImageReader.java [10:27] gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfImageReader.java: ISO-8859 C program text [10:27] blackpad:/soft/BZR/geotools/trunk> file gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfReadParam.java [10:27] gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfReadParam.java: ASCII C program text [10:27] and are you experiencing that bug on linux? with 0.91? [10:28] I'm on ubuntu feisty (utf-8) [10:28] >>find . -name '\.svn' | xargs grep rm -Rf [10:28] is that really the command you ran? [10:28] but there must be files in ISO-8859 in other parts of the tree that imported find [10:28] i don't think that will do what you intend it to do [10:28] no [10:28] without the grep probably [10:29] but something like that [10:29] I couldn't get find to work on its own [10:29] find -name '\.svn' -exec rf -rf \{\} \; [10:29] s/ rf / rm / [10:29] yeah [10:30] I didn't find that and gave up after a while ;-) [10:30] actually the find had '-type d' [10:30] just fyi, it would be easier to just put .svn in a .bzrignore in the root [10:30] in fact it may be on by default [10:30] before running bzr? [10:30] that's nice [10:30] New bug: #148884 in bzr "'bzr add' and 'bzrsvn branch' work but have st with a 'removed:' section" [Undecided,New] https://launchpad.net/bugs/148884 [10:31] before running add [10:31] makes sense now [10:32] bzrsvn should certainly make .svn ignored by default, does that project use the same bugtracker? === gabe [n=gabriel@91.84.56.254] has joined #bzr [10:34] yeah, another directory that imported fine has files in the 8859 locale === pbor [n=urk@host42-87-dynamic.1-79-r.retail.telecomitalia.it] has joined #bzr === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr [10:44] Does 0.91 require Python 2.4 now? [10:44] I get a syntax error on 2.3 for: from stat import (S_ISREG, S_ISDIR, S_ISLNK, ST_MODE, ST_SIZE, [10:45] I didn't see that anywhere in the relnotes. [10:47] mkanat, i don't think we've supported 2.3 for quite a while? [10:47] poolie_: It seems to have been working in 0.18. [10:47] acuster, yes, it's bzr-svn [10:47] !! [10:48] Oh, no, I'm a liar. === poolie_ is now known as poolie_phone [10:48] poolie_: You can ignore me. :-) [10:48] Or at least, that last statement. :-) === fog [n=fog@debian/developer/fog] has joined #bzr === 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 === herzel104 [i=herzel@gateway/tor/x-7cc0413af5b3fc6e] has joined #bzr === Demitar [n=demitar@c-212-031-182-147.cust.broadway.se] has joined #bzr [12:19] poolie_phone, did you mean it's bzr-svn's error? === Zindar [n=erik@stockholm.ardendo.se] has joined #bzr === g0ph3r [n=g0ph3r@p57A0A0C7.dip0.t-ipconnect.de] has joined #bzr [12:55] New bug: #148908 in bzr "`bzr log --short -rX.Y.Z` gives traceback" [Undecided,New] https://launchpad.net/bugs/148908 === mwhudson_ [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr === mwhudson_ is now known as mwhudson === orutherfurd [n=orutherf@dsl092-164-022.wdc2.dsl.speakeasy.net] has joined #bzr [01:30] acuster: I think he meant that launchpad is used for tracking bugs in bzr-svn and the product name there is 'bzr-svn' [01:30] oh, right, thanks === cprov-Zzz is now known as cprov === vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net] has joined #bzr === niemeyer [n=niemeyer@200-140-230-150.ctame705.dsl.brasiltelecom.net.br] has joined #bzr === orospakr [n=orospakr@bas4-ottawa23-1088827158.dsl.bell.ca] has joined #bzr === mw|out [n=mw@189.146.12.253] has joined #bzr === mw|out is now known as mw === bigdog [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr === juliank [n=juliank@f048226155.adsl.alicedsl.de] has joined #bzr === GaryvdM [n=chatzill@41.208.50.176] has joined #bzr === asak_ is now known as asak [03:25] how do I ask for the log of the last 20 revisions? [03:25] bzr log --limit=20 [03:25] ah, or -10.. [03:25] is there a way to do a range? say -20 to -10? === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #bzr [03:26] bzr log -r..... [03:27] ah, I was using .. wrong [03:28] thanks [03:28] Pleasure === bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr === keir [n=keir@206-248-159-250.dsl.teksavvy.com] has joined #bzr === jezdez_ [n=jezdez@pD951163D.dip0.t-ipconnect.de] has joined #bzr [03:46] hi [03:50] I'm trying to checkout a svn repository with bzr-svn from a google code hosting project. I know that I need to use ``bzr co svn+https://..``, though I don't get asked for the password. any ideas? === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr [03:56] New bug: #148964 in bzr "bzr update only reports one conflict" [Undecided,New] https://launchpad.net/bugs/148964 === kiko [n=kiko@canonical/launchpad/pdpc.supporter.active.kiko] has left #bzr ["Left] === acuster is totally confused by branches vs checkouts [03:59] can we branch just a single directory? [03:59] ah! subversion has poisoned your brain i see! [04:00] can I run bzr branch from above the hierarchy? [04:00] perhaps. [04:00] more seriously: no, bazaar versions branches and treats them more or less indivisibly [04:00] and all branches use essentially the same amount of space? [04:01] what's the difference then with a cp -R ? [04:02] i lack enough context to answer sensibly [04:02] say I want a master branch that stays in sync with svn and then lots of 'branch|checkout|trees' to work on individual aspects of the code (cleanup, featureA, featureB...) [04:02] acuster: are you familiar with shared repositories? === acuster lacks enough context ... :-) [04:03] I've worked with cvs and svn for a number of years [04:03] without using branches as much as possible [04:03] for reasons well understood by all [04:04] ok [04:04] so there are two things that can occupy space [04:04] I would like one local branch to be a clean copy of svn with merges to it immediately followed by pushes to svn [04:04] and then I want to work in lots of other 'spaces' [04:04] the historical data, i.e. all the revisions [04:04] and the working trees [04:05] a shared repository lets you store all the historical data in once place for several branches [04:05] history = .bzr and tree = the code hierarchy? [04:05] more or less [04:05] history = .bzr/repository [04:06] there is some other stuff in there too [04:06] ok [04:06] New bug: #148969 in bzr "conflict status flag missing in `bzr update` output" [Undecided,New] https://launchpad.net/bugs/148969 [04:06] so I need to learn how to use 'shared repositories'? [04:06] if you're worried about historical data filling up your hard drive, yes [04:07] shared repos can have non linear histories, right? [04:07] sure [04:07] a repo isn't very interesting, really [04:07] it's just a database in some sense, a stack of revisions [04:07] a stack or a tree? [04:07] well [04:08] having a revision implies also having its parents [04:08] but a repository by it self has no more structure than that [04:09] so the master branch is the 'shared repositiory' and then I create slave branches off of that for each project? [04:09] and i can commit/revert on the slaves until ready to merge back to the master? [04:09] if so, what are the 'slaves' called? checkouts, branches, ...? [04:09] um [04:10] There are no slaves or masters in bzr; all are created equal [04:10] all *what* is the question [04:10] ((quite like SATA I guess :) )) [04:10] do I need n branches? [04:11] if so, is making n branches with bzr branch exactly the same thing as making n branches with cp -R ? [04:11] acuster: branches [04:12] the web site talks about 'working trees' without giving examples or saying how to create them [04:12] A working tree is the checkout.. the place you work in [04:12] bzr checkout http://foo/bar... <== now I have a working tree [04:12] acuster: sorry, i'm too occupied to really do a good job of explaining ... [04:12] hopefully LeoNerd can do better :) [04:13] mwhudson, thanks [04:13] The working tree is the tree, where you work. (kinda obvious that bit :) ) [04:13] LeoNerd, backup a second [04:13] we start with an svn server on the net http://svn... [04:13] OK.. I know as little as possible about svn... [04:14] i want a local copy of that and want to be very careful about pushes/pulls to that svn server [04:14] so i have started with bzr branch http://svn... [04:14] okay? [04:14] ok [04:14] so I have .../trunk/.bzr and ../trunk/gt etc [04:14] ok [04:14] now I would like to create some spaces to do some work [04:15] and then when I am done in one of those spaces [04:15] merge that work to the first branch [04:15] then push from that branch back onto the net [04:15] Right... [04:15] so I want,say, 4 local spaces to work [04:15] So that's just bzr branch and bzr push [04:15] what are those? checkouts, branches? [04:15] (and maybe merge if the history has changed) [04:16] 4 branches [04:16] okay, thanks [04:16] Explain more clealry [04:16] so, a final question, [04:16] These "local spaces".. do they contain the actual files, that you might edit in e.g. vim? [04:16] if a branch has all the info it needs, [04:16] what's the difference between bzr branch localdir1 localdir2 [04:16] and cp -R localdir1 localdir2 ? [04:17] Not much [04:17] since both will have .bzr and all the files [04:17] Just 'bzr branch' copies only the .bzr data. [04:17] cp -R will copy every file on the filesystem, regardless of whether it's bzr branch history or not. [04:17]