[01:26] <lifeless> poolie: call ?
[02:20] <ubotu> New bug: #148787 in bzr "rpm packages out of date" [Medium,Confirmed]  https://launchpad.net/bugs/148787
[02:27] <poolie> spiv, hi?
[02:44] <abentley> fullermd: If you start with "branch5/branch6" then switch to "dirstate/dirstate-tags", you have only yourself to blame for the resulting confusion.
[03:18] <spiv> poolie: hi
[03:41] <poolie> spiv, i'm going to get some early lunch, can we talk after that?
[03:43] <spiv> Ok.
[04:09] <lifeless> mmm food
[04:40] <lifeless> poolie: ping re reviews
[04:47] <abadger1999> lifeless: If you find a good replacement, let me know :-)
[04:48] <lifeless> abadger1999: I hear telnet is
[04:59] <mneptok> abadger1999: wat clay, a reed, and knowledge of cuneiform is far superior solution than Evolution
[04:59] <mneptok> *wet
[05:00] <abadger1999> hah!
[05:00] <lifeless> mneptok: its funny cause its true
[05:00] <abadger1999> 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] <mneptok> lifeless: "funny" in that "i really chuckled as i tasted the gun oil" way
[05:01] <poolie> lifeless, i'm reviewing your code
[05:01] <lifeless> mneptok: you're heading for quotes page again
[05:01] <abadger1999> I may have to try sylpheed-claws next.
[05:01] <lifeless> poolie: thank you!
[05:02] <lifeless> poolie: sypy is on tonight btw, I plan to head along
[05:06] <mneptok> 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] <lifeless> poolie: I've sent 3 new up today I think
[05:08] <lifeless> poolie: I'm going for lunch, if theres something you want to ask me about, ring me please
[05:09] <poolie> hello mneptok
[05:09] <poolie> nice to see you
[05:09] <poolie> i wonder what claws is like these days
[05:10] <poolie> 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] <mneptok> poolie: 'allo sahib :)
[05:11] <jml> poolie: kind of like an offline gmail then?
[05:12] <mneptok> poolie: Claws' performance vis-a-vis speed is excellent. performance vis-a-vis data integrity ... not so much. in my experience.
[05:12] <poolie> jml, gmail is pretty close to doing it for me
[05:13] <poolie> better keyboard support would be nice
[05:13] <mneptok> Greasemonkey?
[05:13] <poolie> builtin gpg handling would be good too, though i realize some hacks are possible with encrypting the clipboard etc
[05:13] <jml> poolie: my main gripe is that it needs internet and "open next email" takes too long (because of internet)
[05:14] <poolie> mneptok, you know you could probably get in trouble making that proposition to some people
[05:14] <poolie> :)
[05:14] <radix> poolie: I've been using some firefox extension to add gpg support to gmail. it's not bad.
[05:14] <poolie> after using gmail for a while i just switched to evo to see how it was
[05:15] <poolie> too many crashes
[05:15] <mneptok> poolie: only if on follow-through my techique is sub-par ;)
[05:15] <poolie> hello radix
[05:15] <radix> hi poolie :-)
[05:21] <lifeless> back
[05:22] <lifeless> evo would be really good if its developers used it
[05:24] <abadger1999> if it's developers used it, they'd all kill themselves.
[05:29] <lifeless> nah
[05:29] <lifeless> but they would fix it
[05:41] <lifeless> hmm what to do
[05:44] <poolie> spiv, hi?
[05:47] <spiv> poolie: hello
[05:48] <poolie> call?
[05:48] <spiv> poolie: want to call?
[05:48] <spiv> snap
[05:54] <mneptok> lifeless: i find it unlikely Microsoft employees would actually use Evolution
[05:54] <mneptok> *bah dum tish*
[05:54] <lifeless> mneptok: bitchy
[05:54] <lifeless> I like it
[06:04] <mneptok> :)
[06:19] <lifeless> poolie: replied to your review
[06:27] <poolie> >Would you prefer a[:]  = []  ?
[06:27] <poolie> well
[06:28] <poolie> when i first read it, i didn't see the [:]  and wondered "why on earth is he deleting it"?
[06:28] <poolie> then about 10s later i saw it
[06:28] <lifeless> I find the del clearer
[06:28] <lifeless> because [:]  list replacement is IME rarely used
[06:28] <lifeless> and the point here is to preserve the instance of the list
[06:29] <poolie> yes, i understand that
[06:29] <lifeless> I wouldn't want someone to do a = []  as a 'cleanup'
[06:29] <poolie> exactly
[06:30] <poolie> maybe you should add a comment explaining you need to keep the instance?
[06:32] <lifeless> sure
[06:32] <poolie> 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] <poolie> but, that's neither here nor there
[06:33] <poolie> your response is fine with me, anyhow
[06:33] <lifeless> thanks! 1 down, X to go :)
[06:38] <poolie> oh, abadger1999 is toshio
[06:38] <poolie> i presume
[06:39] <abadger1999> Yep.
[06:40] <abadger1999> Looking at the Fedora Packaging bug?
[06:46] <lifeless> speaking of packaging, I've still got this glitch
[06:55] <keir> abentley, ping
[06:56] <abentley> pong
[06:59] <lifeless> hi keir
[07:00] <lifeless> 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] <lifeless> keir: also, have you done any performance tests with your code?
[07:09] <poolie> 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] <poolie> it also made me smile because my partner is a tiki enthusiast
[07:10] <abadger1999> Ah :-)
[07:17] <lifeless> poolie: do I get any other reviews ? :)
[07:18] <poolie> i've done all but one of them
[07:18] <poolie> by BB's count
[07:18] <lifeless> oh hmm
[07:18] <poolie> i can do that one after matthew's, if you like
[07:26] <lifeless> poolie: please do
[07:31] <keir> lifeless, no, i haven't done any perf testing yet
[07:32] <keir> abentley, if you're going to make a trac-killer, go for full distributed
[07:32] <keir> abentley, and i feel rather strongly that the killer feature of trac is the pervasive wiki
[07:32] <abentley> Well, it sounds like you need to write your own.
[07:32] <keir> abentley, if i could have local editing of the wiki along with the trac wiki integration for tickets and such... sweeet
[07:33] <keir> abentley, so you're not going to try distributed?
[07:33] <lifeless> I think wiki integration is killer; I think trac's including the wiki is whack
[07:33] <abentley> If it's successful, it might expand that way.
[07:33] <abentley> But distributed is really complicated.
[07:33] <lifeless> better to work closely with a wiki that is just a great wiki, than write a new one
[07:34] <lifeless> abentley: btw, I love the name
[07:34] <abentley> And I don't need that right now.
[07:35] <keir> i was thinking something that used ReST
[07:35] <keir> lightweight
[07:35] <keir> actually, i like the name, but i think it is a bad idea
[07:35] <keir> because it is not googleable
[07:35] <keir> the new project 'review board' for example. WORST NAME EVER
[07:35] <keir> try finding that one!
[07:36] <abentley> lifeless: Thanks.  I saw it there, and I figured I had to use it, but it's probably just a working title.
[07:36] <keir> lifeless, if we toss the split between data / key, then we can't topo sort
[07:36] <abentley> I think it's amusing that "Trac" is actually a real word backwards.
[07:37] <lifeless> keir: I'm pretty sure you are wrong
[07:38] <keir> lifeless, then how are you going to find keys?
[07:38] <keir> lifeless, you can't build a btree on keys anymore because they're not sorted
[07:38] <lifeless> well
[07:38] <keir> 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] <lifeless> 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] <lifeless> I raised this in my first design review on the list
[07:39] <keir> right
[07:39] <abentley> keir: Making a distributed wiki is one thing.  That's basically just using Bazaar as a wiki backend.
[07:39] <lifeless> another way of getting grouping is to keep the keys and data together, and to index on topological index
[07:39] <abentley> But a distributed bug tracker with correct merging is a lot more complicated.
[07:40] <lifeless> (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] <keir> lifeless, then you have another entire copy of the keys, no?
[07:40] <lifeless> no
[07:40] <lifeless> not at this point in the sketch anyhow :)
[07:40] <keir> i give you a key. how do you find the data in the 'btree' say?
[07:41] <lifeless> theres no tree in this thought experiment
[07:41] <keir> ok
[07:41] <lifeless> just linear grouping based on topo ordering
[07:41] <keir> so how do you do better than linear scan?
[07:41] <lifeless> finding an arbitrary key by name is linear
[07:41] <keir> ok
[07:41] <keir> so to beat linear
[07:41] <keir> you have to build an index on the keys
[07:41] <lifeless> not necessarily
[07:41] <keir> to find their topo index
[07:41] <lifeless> it depends on what operations are common
[07:41] <lifeless> see, this pattern:
[07:42] <lifeless> find key X
[07:42] <lifeless> find key[X.parent] 
[07:42] <lifeless> etc
[07:42] <keir> right
[07:42] <keir> but if you want to do better than linear for 1st step
[07:42] <lifeless> are amortised linear(index size) for the first op, plus constant time for every additional step
[07:42] <keir> you're sunk because you need to build an index on the keys...
[07:43] <lifeless> there are two reasons to have fast access to an individual key
[07:44] <lifeless> one is direct access to it
[07:44] <lifeless> the second is to make the miss-case fast(because its as slow as the worst case key lookup)
[07:44] <lifeless> its possible to address the second reason without addressing the first via bloom filters, if we want to.
[07:44] <lifeless> bloom filters are very fast
[07:45] <lifeless> now, I suspect we do need reasonably fast direct access
[07:45] <lifeless> and I'm still mulling this
[07:45] <keir> i don't see any way to have fast direct access without an index on the keys
[07:45] <keir> which implies at least 1 copy of the keys sorted by keys
[07:45] <lifeless> I suspect we have 2-3 versions of indices to get a really really good one
[07:46] <lifeless> well, copy of the keys is misleading because you can index on much less than the sum of the keys
[07:46] <lifeless> via e.g. hash'es, tries,
[07:47] <keir> sure, if we go the hash route
[07:47] <lifeless> you can probe in a hash table to get a list of byte offsets the key may be at
[07:47] <lifeless> 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] <lifeless> no key data, and a variable length hash allows this to scale with index size
[07:47] <keir> true
[07:48] <keir> so hash to list of offsets?
[07:48] <lifeless> 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] <keir> sounds reasonable
[07:48] <lifeless> anyhow, project wise -
[07:48] <keir> i can do that
[07:48] <lifeless> I have 3 weeks more or less before UDS
[07:48] <lifeless> but we freeze well before that
[07:48] <lifeless> so here is what I'm thinking...
[07:49] <poolie> lifeless, ok, all your patches that i can see are now merged
[07:49] <poolie> i mean, reviewed
[07:50] <lifeless> 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] <keir> lifeless, sounds sensible
[07:50] <lifeless> 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] <keir> lifeless, yes. if adding topo sorting isn't too hard, i'll do that after.
[07:50] <lifeless> 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.
[07:52] <keir> ok, i have to run
[07:52] <poolie> lifeless, what if anything did you decide about the gsoc summit?
[07:52] <keir> i may hop on over the weekend
[07:52] <lifeless> keir: ok, bye!
[07:53] <lifeless> poolie: hot damn I entirely forgot to look that up
[07:53] <lifeless> you wouldn't happen to know where the announcement stuff is? I haven't been emailed about it so have no links
[07:54] <poolie> uh i think it's next weekend so probably not
[07:54] <poolie> http://groups.google.com/group/google-summer-of-code-mentors-list/browse_thread/thread/7632570e13d7813e/e69899cd12d7c7ad#e69899cd12d7c7ad
[07:54] <poolie> iow, in two days time
[07:54] <poolie> "can i borrow your jet?"
[07:55] <lifeless> meep
[07:56] <lifeless> guess not lol
[07:56] <lifeless> hmm, bb says its reviewed, but I don't see mail about it
[07:56] <lifeless> the fetch patch
[07:58] <poolie> after i finish vila's patch i'm going to take a break as i have calls tonight
[07:59] <poolie> then will submit my patch
[07:59] <lifeless> ok
[07:59] <lifeless> please let them know that the packs patch is very small now, with these things reviewed
[08:00] <lifeless> and I'll be doing the index thing as the next priority
[08:00] <lifeless> so Monday I hope to be sending in the last patch to remove the packs branch
[08:00] <lifeless> that is to merge the entire thing
[08:02] <poolie> lifeless, what is the real difference in intention between tests/blackbox and tests/commands?
[08:02] <poolie> the docstring is not very enlightening
[08:02] <lifeless> search me, let me look
[08:03] <lifeless> vila seems to have created this
[08:03] <lifeless> poolie: commands/ invokes the objects directly
[08:03] <lifeless> poolie:         cmd = cmd_cat()
[08:03] <lifeless>         cmd.run(self.get_url('branch/foo'))
[08:04] <lifeless>         self.assertEquals(1, len(self.connections))
[08:04] <lifeless>         self.assertEquals('foo', self.outf.getvalue())
[08:04] <lifeless> so it is avoiding the run_bzr* infrastructure, its a lower level test.
[08:04] <lifeless> I think this is quite reasonable but the docstring is as you say unclear
[08:04] <poolie> yes that does seem to be it
[08:05] <poolie> to me, that layer seems so thin that it is not worth separately testing with and without it
[08:06] <lifeless> I don't like the idea of duplicate tests with and without it
[08:06] <lifeless> I would quite like to have tests of that layer and all the others tests written without it; personally.
[08:07] <lifeless> anyhow, I'm out for the day; got lots done
[08:14] <poolie> lifeless, any debs yet?
[08:14] <poolie> tests of the argument parsing and everything else done without parsing?
[08:14] <poolie> that would be ok with me
[08:14] <poolie> i think
[08:15] <ubotu> New bug: #148857 in bzr "add should not show count of ignored files" [Low,Confirmed]  https://launchpad.net/bugs/148857
[08:37] <lifeless> poolie: yes, just now in fact.
[08:37] <lifeless> poolie: without sid, its failing to build for me
[08:59] <vila> 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] <vila> and also to create a dedicated transport (based on ftp) to avoid testing against all transports
[09:01] <vila> the distinction between blackbox (testing the API) and tests/commands for the internal behavior was a bit blurry though :-/
[09:02] <vila> 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
[09:09] <mkanat> Is there any way to get a log for all of the items in a directory?
[09:09] <mkanat> Particularly from a repo with no working tree.
[09:10] <lifeless> vila: well I advised that when you asked a specific quest
[09:11] <lifeless> question
[09:11] <vila> lifeless: I'm not throwing stones ;)
[09:11] <lifeless> :)
[09:11] <lifeless> I'm off to sypy
[09:11] <vila> just explaining the history to help find the right answer
[09:12] <vila> which I still don't have unfortunately :-/
[09:12] <lifeless> ciao
[09:15] <vila> 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...
[09:22] <acuster> 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] <acuster> However, bzr log lists a bunch of files under a "removed:" header
[09:23] <acuster> the same thing happened when I did a bzr init; bzr add on a fresh svn checkout
[09:24] <acuster> can anyone explain how bzr is handling those files?
[09:52] <acuster> after 'bzr revert' is 'bzr st' supposed to have a 'removed:' section?
[09:59] <poolie_> acuster, no, it should normally not
[09:59] <acuster> thanks
[10:00] <acuster> does bzr make errors building a repository due to file name issues, file content issues or layouts?
[10:17] <poolie_> can you explain the question more?
[10:22] <acuster> https://bugs.launchpad.net/bzr/+bug/148884
[10:22] <ubotu> Launchpad bug 148884 in bzr "'bzr add' and 'bzrsvn branch' work but have st with a 'removed:' section" [Undecided,New] 
[10:22] <acuster> would bzr have issues on files in different encodings?
[10:24] <poolie_> looking
[10:24] <acuster> thanks
[10:25] <poolie_> that is strange
[10:25] <poolie_> bzr handles filenames as unicode
[10:26] <poolie_> so it does have trouble if there are names that are not valid in your machine's encoding
[10:26] <acuster> the file names look ok, I was thinking in terms of contents
[10:27] <poolie_> generally no, though there are some more things we'd like to do to accomodate people with varying encodings within their tree
[10:27] <poolie_> that is, with files whose encoding doesn't match your locale's encoding
[10:27] <acuster> blackpad:/soft/BZR/geotools/trunk> file gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfImageReader.java
[10:27] <acuster> gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfImageReader.java: ISO-8859 C program text
[10:27] <acuster> blackpad:/soft/BZR/geotools/trunk> file gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfReadParam.java
[10:27] <acuster> gt/modules/unsupported/coverageio-netcdf/src/main/java/org/geotools/image/io/netcdf/NetcdfReadParam.java: ASCII C program text
[10:27] <poolie_> and are you experiencing that bug on linux? with 0.91?
[10:28] <acuster> I'm on ubuntu feisty (utf-8)
[10:28] <poolie_> >>find . -name '\.svn' | xargs grep rm -Rf
[10:28] <poolie_> is that really the command you ran?
[10:28] <acuster> but there must be files in ISO-8859 in other parts of the tree that imported find
[10:28] <poolie_> i don't think that will do what you intend it to do
[10:28] <acuster> no
[10:28] <acuster> without the grep probably
[10:29] <acuster> but something like that
[10:29] <acuster> I couldn't get find to work on its own
[10:29] <mkanat> find -name '\.svn' -exec rf -rf \{\} \;
[10:29] <mkanat> s/ rf / rm /
[10:29] <acuster> yeah
[10:30] <acuster> I didn't find that and gave up after a while ;-)
[10:30] <acuster> actually the find had '-type d'
[10:30] <poolie_> just fyi, it would be easier to just put .svn in a .bzrignore in the root
[10:30] <poolie_> in fact it may be on by default
[10:30] <acuster> before running bzr?
[10:30] <acuster> that's nice
[10:30] <ubotu> 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] <poolie_> before running add
[10:31] <acuster> makes sense now
[10:32] <acuster> bzrsvn should certainly make .svn ignored by default, does that project use the same bugtracker?
[10:34] <acuster> yeah, another directory that imported fine has files in the 8859 locale
[10:44] <mkanat> Does 0.91 require Python 2.4 now?
[10:44] <mkanat> I get a syntax error on 2.3 for: from stat import (S_ISREG, S_ISDIR, S_ISLNK, ST_MODE, ST_SIZE,
[10:45] <mkanat> I didn't see that anywhere in the relnotes.
[10:47] <poolie_> mkanat, i don't think we've supported 2.3 for quite a while?
[10:47] <mkanat> poolie_: It seems to have been working in 0.18.
[10:47] <poolie_> acuster, yes, it's bzr-svn
[10:47] <poolie_> !!
[10:48] <mkanat> Oh, no, I'm a liar.
[10:48] <mkanat> poolie_: You can ignore me. :-)
[10:48] <mkanat> Or at least, that last statement. :-)
[12:19] <acuster> poolie_phone, did you mean it's bzr-svn's error?
[12:55] <ubotu> New bug: #148908 in bzr "`bzr log --short -rX.Y.Z` gives traceback" [Undecided,New]  https://launchpad.net/bugs/148908
[01:30] <jelmer> 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] <acuster> oh, right, thanks
[03:25] <acuster> how do I ask for the log of the last 20 revisions?
[03:25] <GaryvdM> bzr log --limit=20
[03:25] <acuster> ah, or -10..
[03:25] <acuster> is there a way to do a range? say -20 to -10?
[03:26] <GaryvdM> bzr log -r.....
[03:27] <acuster> ah, I was using .. wrong
[03:28] <acuster> thanks
[03:28] <GaryvdM> Pleasure
[03:46] <jezdez_> hi
[03:50] <jezdez_> 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?
[03:56] <ubotu> New bug: #148964 in bzr "bzr update only reports one conflict" [Undecided,New]  https://launchpad.net/bugs/148964
[03:59] <acuster> can we branch just a single directory?
[03:59] <mwhudson> ah! subversion has poisoned your brain i see!
[04:00] <acuster> can I run bzr branch from above the hierarchy?
[04:00] <acuster> perhaps.
[04:00] <mwhudson> more seriously: no, bazaar versions branches and treats them more or less indivisibly
[04:00] <acuster> and all branches use essentially the same amount of space?
[04:01] <acuster> what's the difference then with a cp -R ?
[04:02] <mwhudson> i lack enough context to answer sensibly
[04:02] <acuster> 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] <mwhudson> acuster: are you familiar with shared repositories?
[04:03] <acuster> I've worked with cvs and svn for a number of years
[04:03] <acuster> without using branches as much as possible
[04:03] <acuster> for reasons well understood by all
[04:04] <mwhudson> ok
[04:04] <mwhudson> so there are two things that can occupy space
[04:04] <acuster> 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] <acuster> and then I want to work in lots of other 'spaces'
[04:04] <mwhudson> the historical data, i.e. all the revisions
[04:04] <mwhudson> and the working trees
[04:05] <mwhudson> a shared repository lets you store all the historical data in once place for several branches
[04:05] <acuster> history = .bzr and tree = the code hierarchy?
[04:05] <mwhudson> more or less
[04:05] <mwhudson> history = .bzr/repository
[04:06] <mwhudson> there is some other stuff in there too
[04:06] <acuster> ok
[04:06] <ubotu> New bug: #148969 in bzr "conflict status flag missing in `bzr update` output" [Undecided,New]  https://launchpad.net/bugs/148969
[04:06] <acuster> so I need to learn how to use 'shared repositories'?
[04:06] <mwhudson> if you're worried about historical data filling up your hard drive, yes
[04:07] <acuster> shared repos can have non linear histories, right?
[04:07] <mwhudson> sure
[04:07] <mwhudson> a repo isn't very interesting, really
[04:07] <mwhudson> it's just a database in some sense, a stack of revisions
[04:07] <acuster> a stack or a tree?
[04:07] <mwhudson> well
[04:08] <mwhudson> having a revision implies also having its parents
[04:08] <mwhudson> but a repository by it self has no more structure than that
[04:09] <acuster> so the master branch is the 'shared repositiory' and then I create slave branches off of that for each project?
[04:09] <acuster> and i can commit/revert on the slaves until ready to merge back to the master?
[04:09] <acuster> if so, what are the 'slaves' called? checkouts, branches, ...?
[04:09] <mwhudson> um
[04:10] <LeoNerd> There are no slaves or masters in bzr; all are created equal
[04:10] <acuster> all *what* is the question
[04:10] <LeoNerd> ((quite like SATA I guess :) ))
[04:10] <acuster> do I need n branches?
[04:11] <acuster> if so, is making n branches with bzr branch exactly the same thing as making n branches with cp -R ?
[04:11] <mwhudson> acuster: branches
[04:12] <acuster> the web site talks about 'working trees' without giving examples or saying how to create them
[04:12] <LeoNerd> A working tree is the checkout.. the place you work in
[04:12] <LeoNerd> bzr checkout http://foo/bar...     <== now I have a working tree
[04:12] <mwhudson> acuster: sorry, i'm too occupied to really do a good job of explaining ...
[04:12] <mwhudson> hopefully LeoNerd can do better :)
[04:13] <acuster> mwhudson, thanks
[04:13] <LeoNerd> The working tree is the tree, where you work. (kinda obvious that bit :) )
[04:13] <acuster> LeoNerd, backup a second
[04:13] <acuster> we start with an svn server on the net http://svn...
[04:13] <LeoNerd> OK.. I know as little as possible about svn...
[04:14] <acuster> i want a local copy of that and want to be very careful about pushes/pulls to that svn server
[04:14] <acuster> so i have started with bzr branch http://svn...
[04:14] <acuster> okay?
[04:14] <GaryvdM> ok
[04:14] <acuster> so I have .../trunk/.bzr and ../trunk/gt etc
[04:14] <GaryvdM> ok
[04:14] <acuster> now I would like to create some spaces to do some work
[04:15] <acuster> and then when I am done in one of those spaces
[04:15] <acuster> merge that work to the first branch
[04:15] <acuster> then push from that branch back onto the net
[04:15] <LeoNerd> Right...
[04:15] <acuster> so I want,say, 4 local spaces to work
[04:15] <LeoNerd> So that's just bzr branch  and  bzr push
[04:15] <acuster> what are those? checkouts, branches?
[04:15] <LeoNerd> (and maybe merge  if the history has changed)
[04:16] <GaryvdM> 4 branches
[04:16] <acuster> okay, thanks
[04:16] <LeoNerd> Explain more clealry
[04:16] <acuster> so, a final question,
[04:16] <LeoNerd> These "local spaces".. do they contain the actual files, that you might edit in e.g. vim?
[04:16] <acuster> if a branch has all the info it needs,
[04:16] <acuster> what's the difference between bzr branch localdir1 localdir2
[04:16] <acuster> and cp -R localdir1 localdir2 ?
[04:17] <LeoNerd> Not much
[04:17] <acuster> since both will have .bzr and all the files
[04:17] <LeoNerd> Just 'bzr branch' copies only the .bzr data.
[04:17] <LeoNerd> cp -R will copy every file on the filesystem, regardless of whether it's bzr branch history or not.
[04:17] <LeoNerd> cp -R will also copy locally-modified changes in a checkout, if there is on
[04:17] <LeoNerd> bzr branch will not copy a checkout at all
[04:18] <LeoNerd> 'bzr branch' is, however, moreorless equivalent of cp -R on just the .bzr directory inside that.
[04:18] <acuster> ah, so bzr branch is like cp but only for versioned info?
[04:18] <LeoNerd> Basically, yes.
[04:18] <LeoNerd> (and of course works over other transports like http and sftp and so on)
[04:18] <acuster> does bzr branch have all the same history?
[04:18] <acuster> forget that
[04:18] <GaryvdM> yes
[04:18] <acuster> all branches are equal
[04:18] <LeoNerd> Yes. The two histories will be identical after a 'bzr branch'
[04:19] <acuster> so checkouts are to let you live in svn hell even after moving to bzr?
[04:19] <acuster> thanks you all
[04:20] <GaryvdM> ????
[04:20] <GaryvdM> acuster: please can I try explain somthing to you
[04:20] <acuster> sure
[04:21] <LeoNerd> acuster: Be careful not to be eaten by a Grue
[04:21] <acuster> I wondered if the reference would work... :-)
[04:21] <GaryvdM> A branch contains a repo and a working tree (wt
[04:22] <GaryvdM> repo contains the state of the tree at each version
[04:22] <GaryvdM> the working tree is a place to do your work
[04:23] <GaryvdM> You can create a shared repo
[04:23] <GaryvdM> And put branches inside the shared repo
[04:23] <acuster> (my branch is 954MB, hence my hope I could work without n copies of the same thing)
[04:24] <GaryvdM> But the shared repo only has a repo - no working tree
[04:24] <GaryvdM> Hence it is not a branch its' self
[04:25] <GaryvdM> But the branches that you put inside the shared repo will share there revision history, and hence save space and time.
[04:25] <GaryvdM> Make sense?
[04:25] <acuster> sort of
[04:26] <acuster> how do you go about making a shared repo, starting from a branch?
[04:26] <GaryvdM> ok
[04:26] <acuster> how do you go about making a shared repo, starting from a branch, and then making n branches
[04:26] <mwhudson> bzr init-repo .
[04:26] <GaryvdM> lets say you have projectfoo/trunk is your branch
[04:27] <mwhudson> though with bzr-svn it should be
[04:27] <mwhudson> bzr init-repo --dirtstate-with-subtree . i think
[04:27] <GaryvdM> ren projectfoo projectfoo-temp
[04:27] <GaryvdM> bzr init-repo projectfoo
[04:27] <GaryvdM> cd projectfoo
[04:28] <GaryvdM> bzr branch ../projectfootemp/trunk
[04:28] <GaryvdM> cd ..
[04:28] <GaryvdM> rd projectfoo
[04:28] <acuster> ren?
[04:28] <GaryvdM> rename - sorry i'm a windows user
[04:29] <acuster> rename just changes the name?
[04:29] <GaryvdM> Yes
[04:29] <GaryvdM> branches can just be rename on the filesystem
[04:30] <GaryvdM> s/rename/renamed
[04:30] <acuster> did you forget some chdir in there?
[04:30] <acuster> ls = projectfoo/trunk
[04:31] <acuster> mv projectfoo projectbar
[04:31] <acuster> cd projectbar
[04:31] <GaryvdM> no
[04:31] <acuster> bzr init-repo trunk
[04:31] <acuster> errr
[04:31] <GaryvdM> You need to move the existing branch out the way to a temp place
[04:31] <acuster> okay, thanks for your help. I'll try to walk through that slowly and make sense of it
[04:32] <GaryvdM> Then create the the shared repo
[04:32] <GaryvdM> then branch into the shared repo
[04:32] <GaryvdM> then delete the old temp branch
[04:33] <acuster> so then i have the same branch I had originally except now it is a shared repo as well?
[04:33] <GaryvdM> yes
[04:33] <acuster> which allows one to do what that we could not do before?
[04:33] <mwhudson> it is _in_ a shared repo, or it _uses_ a shared repo
[04:33] <GaryvdM> Save disk space
[04:34] <mwhudson> GaryvdM: you can create the repo in the directory that your branch is in
[04:34] <mwhudson> branch it into another location in the repo (to copy the revisions into the repo)
[04:35] <mwhudson> then delete trunk/.bzr/repository
[04:35] <acuster> because then each branch below that shared repo will be a full copy of the code files but a virtual copy of the repo info?
[04:35] <GaryvdM> yes
[04:35] <acuster> yes to me or to mwh?
[04:35] <GaryvdM> mwhudson: Yhea, but still requires a branch to move the repo to the shared repo
[04:36] <mwhudson> yes
[04:36] <GaryvdM> yes to acuster
[04:36] <mwhudson> it's hacky, but it works :)
[04:36] <acuster> okay, thanks you all. Will go off and try to sort this out
[04:36] <GaryvdM> Cool!
[04:37] <jezdez_> sorry to ask again, but has somebody experience in using bzr with google code hosting via bzr-svn?
[04:38] <mwhudson> jezdez_: i have not, but i don't think google code hosting does anything very exciting
[04:38] <mwhudson> (apart from be not very reliable)
[04:39] <jezdez_> mwhudson: indeed, unfortuneately I actually have no choice and want to use bzr for my changes
[04:40] <mwhudson> so what are you trying, what happens, and how does that differ from what you'd like to happen?
[04:45] <GaryvdM> It's a pleasure
[05:03] <acuster> GaryvdM,  http://bazaar-vcs.org/SharedRepositoryTutorial talks about a --trees flag, has this been made the default?
[05:06] <fullermd> Yes, a couple versions ago.
[05:09] <acuster> aha. if a branch is made without trees, one can do a checkout from that branch to get a tree?
[05:09] <LeoNerd> Indeed
[05:10] <LeoNerd> Any point on any branch may be checked out, to obtain a working tree
[05:10] <jelmer> GaryvdM: hi, still there?
[05:11] <acuster> point == revision?
[05:12] <acuster> and a checkout can be somewhere else entirely on the filesystem?
[05:12] <LeoNerd> Sure.
[05:12] <acuster> this all seems quite lovely
[05:12] <LeoNerd> A "branch" is just a branch
[05:13] <LeoNerd> A "checkout" is usually a directory that contains a branch _and_ a working tree
[05:13] <acuster> there's a totally useless statement
[05:13] <acuster> right
[05:13] <LeoNerd> But you can also, if you want, make a "lightweight" checkout, which contains just the working tree, and references some branch stored elsewhere
[05:13] <acuster> the branch vs tree thing was hard to see
[05:14] <acuster> so what I want is a repo of branches and then a lightweight tree elsewhere on the system
[05:14] <acuster> bzr can generate a tree just from the info in the .bzr dir?
[05:15] <fullermd> Glarble.
[05:21] <acuster> finally bitten by the day's original bug.
[05:24] <GaryvdM> Hi jelmer
[05:26] <jelmer> GaryvdM: just marked some of your merge requests as approved by you, if you wonder what those emails are sent on your behalf :-)
[05:29] <GaryvdM> jelmer: I'm not sure what mails your talking about
[05:30] <jelmer> GaryvdM: see the recent few mails to the bzr-gtk mailing list
[05:30] <GaryvdM> Ok - now I see them in the archive
[05:30] <GaryvdM> :-) not sent to my mail
[05:49] <poolfool> Has anyone attempted to modify the index.tmpl for the bazaar-hgweb (3rd party) plugin? I don't think it works how the instructions describe it.
[06:07] <Alien_Freak> new at bzr, looking for a getting started guide/howto.... also, any info on importing svn into bzr?
[06:08] <Peng> Alien_Freak: There's lots on http://bazaar-vcs.org/ .
[06:08] <Peng> Alien_Freak: There's also information on conversion.
[06:09] <Alien_Freak> okay.. thanks
[06:09] <Peng> Sorry, I'd give you a link, but I don't exactly have a web browser open at the moment.
[06:12] <james_w> Alien_Freak: doc.bazaar-vcs.org/bzr.dev/
[06:12] <james_w> there is a quickstart tutorial on there.
[06:12] <Peng> That too.
[06:12] <Alien_Freak> ok.. ty
[06:14] <GaryvdM> jelmer: When you say test, did you mean unit test?
[06:17] <jelmer> GaryvdM: yes
[06:17] <GaryvdM> Please could you give me some pointers
[06:18] <GaryvdM> To test it you would you not need a server setup?
[06:18] <jelmer> GaryvdM: yes, but bzr's testsuite already does that
[06:19] <GaryvdM> a filezilla server?
[06:19] <jelmer> GaryvdM: at least some bits appear to be in bzrlib/tests/test_ftp_transport.py
[06:19] <jelmer> no, but it should be customizable - iirc it's a mock ftp server, but I may be wrong
[06:20] <GaryvdM> Oh - ok
[06:20] <jelmer> if that is not the case, you should be able to test that _translate_perm_error() returns the right exception when it gets that error that filezilla returns
[06:30] <jezdez_> mwhudson: so, sorry for this delay, the kids needed to have dinner :)
[06:30] <mwhudson> jezdez_: luckily jelmer seems to be around now and he's much more qualified than me to answer
[06:30] <mwhudson> :)
[06:31] <jezdez_> mwhudson: ah great
[06:31] <ubotu> New bug: #149019 in bzr "locations.conf error message has bad line count" [Undecided,New]  https://launchpad.net/bugs/149019
[06:31] <jezdez_> jelmer: I'm trying to checkout a google hosted project with bzr-svn
[06:32] <jelmer> jezdez_: what error are you getting?
[06:32] <jezdez_> jelmer: bzr: ERROR: Permission denied: ".": PROPFIND request failed on '/svn/trunk'
[06:33] <jelmer> jezdez_: please try prefixing the url you are trying to check out with svn+
[06:33] <jelmer> jezdez_: google gives permission denied errors rather than "no such file error"s for some reason
[06:33] <jezdez_> jelmer: I tried "bzr checkout svn+https://USERNAME@PROJECTNAME.googlecode.com/svn/trunk/"
[06:34] <jezdez_> jelmer: google advices to use something like this in a normal svn environment: "svn checkout https://PROJECTNAME.googlecode.com/svn/trunk/ --username USERNAME"
[06:35] <jezdez_> for a non-anonymous checkout
[06:36] <jelmer> jezdez_: have you tried running something like 'svn ls https://PROJECTNAME.googlecode.com/svn/trunk/ --username USERNAME' ?
[06:37] <jezdez_> jelmer: yes, works as it should, listing file in the trunk directory
[06:38] <jelmer> hmm, in that case the checkout using bzr should also work now
[06:39] <jezdez_> jelmer: huh, you are right.. now it works. it seems to cache the username input..
[06:40] <jelmer> yeah, password prompting isn't done by bzr-svn at the moment (yet) :-/
[06:40] <jelmer> however, it can use the native svn cache
[06:41] <jezdez_> jelmer: ah, ok.. thanks for putting up this kind of wrapper anyway :) I was looking for such a workaround
[06:43] <poolfool> What are people using to publish a web view of their bzr 'shared repo'; ie something like ViewVC?
[06:43] <jelmer> poolfool: loggerhead mostly
[06:43] <jelmer> jezdez_: No worries, hopefully we'll get the prompting in by the next release...
[06:44] <jelmer> poolfool: e.g. http://codebrowse.launchpad.net/~jelmer/bzr-svn/0.4/changes
[06:44] <jezdez_> jelmer: great to hear that, thanks for your help.
[06:44] <poolfool> jelmer: So the common answer is 'launchpad' you fool.  Ok, what about if I want to self host and not use turbogears?
[06:45] <jelmer> poolfool: you can run loggerhead yourself
[06:45] <poolfool> jelmer: Errr ... not use launchpad?
[06:45] <jelmer> poolfool: launchpad just uses it too
[06:46] <james_w> poolfool: there is also bazaar-webserve
[06:46] <poolfool> jelmer: Thanks .... I have been a CVS guy for a while and I have a lot of the office using CVS. Our current setup is CVS-NT on a Linux server with tortuousCVS client and ViewVC for access. I am trying to find the same kind of setup.
[06:47] <poolfool> james_w: what is the address for bazaar-webserve?
[06:48] <mwhudson> poolfool: what is your problem with loggerhead?
[06:48] <james_w> http://goffredo-baroncelli.homelinux.net/bazaar
[06:50] <poolfool> mwhudson: Actually nothing ... I am just getting into python and not sure I will be able to adapt loggerhead as I want. I know enough perl (shudder) to modify ViewVC to my liking.
[06:51] <poolfool> muwhudson: That and I am currently running apache ... doesn't loggerhead require cherrypy?
[06:52] <poolfool> james_w: I have been looking at that a lot right now, found it under the 3rd party plug-ins page. But I am having a problem modifying the index.tpl(?) file as defined in the 'docs'. Changes are not showing up on the page?
[06:52] <mwhudson> poolfool: yes, sadly :/
[06:52] <mwhudson> poolfool: you can reverse proxy it though
[06:53] <poolfool> mwhudson: I guess my ideal (ha ha) solution would be ViewVC support bzr as well.
[06:53] <poolfool> mwhudson: ??? Do you mean redirect from apache to cherrypy?
[06:54] <mwhudson> given how different bzr and svn are in someways, i don't think viewvc _can_ support bzr sensibly
[06:54] <mwhudson> (imho)
[06:54] <mwhudson> poolfool: proxy internally, you know, the usual way you run a long running process behind apache?
[06:54] <mwhudson> ProxyPass and all that
[06:55] <poolfool> mwhudson: I totaly agree, I actualy really like bazaar-webserve if 1) it supported cherrypy, 2) had a simpler template engine and 3) worked as the documentation described.
[06:55] <jelmer> hasn't bazaar-webserve pretty much been obsoleted by loggerhead? afaik it's not being maintained anymore, is it?
[06:56] <poolfool> jelmer: That is the answer I was looking for, the '.dev' branch has a few commits but it pretty much looks like it's toast. To Bad, it does a lot that loggerhead does not.
[06:56] <james_w> poolfool: are you sure that it is picking up the templates that you think it is?
[06:57] <james_w> it has some strange logic to work out where to load the templates from.
[06:57] <poolfool> james_w: After reading the instructions more then once (or twice), I hope so. I started to leaf through the python code (not my first or second language) to make sure.
[06:57] <LarstiQ> jelmer: it's still maintained.
[06:59] <poolfool> james_w: The process I have tried is 1) install plugin to ~/.bazaar/plugin, 2) check that it works, 3) edit template at '~/.bazaar/plugin/bzrweb/templates/index.tmpl' and 4) cry because its not working?
[06:59] <jelmer> LarstiQ: by whom?
[07:00] <poolfool> james_w: I have tried restarting '#bzr webserve ..... ' multiple times
[07:00] <mwhudson> i promise you loggerhead is more actively maintained, because i'm paid to do it :-)
[07:00] <LarstiQ> jelmer: well, unless Goffredo stopped maintaining it in the period I stopped paying attention to computers..
[07:00] <LarstiQ> mwhudson: that is certainly true
[07:01] <mwhudson> what does bzr-webserve do that loggerhead does not?
[07:01] <jelmer> it doesn't use turbogears I think :-)
[07:02] <poolfool> mwhudson: Well thank you ... it is a great piece of code ... but it's more of a large hammer, that requires (I think) cherrypy.
[07:02] <poolfool> mwhudson: All of that said, Loggerhead is probably my next solution .... so I might ask you a few quesitons.
[07:03] <mwhudson> jelmer: i hope loggerhead won't for too much longer either, i think
[07:04] <poolfool> One of the really nice things about bzr-webserve (I think) it that it doesn't have outside dependencies (cherrypy), you can fire up a web server for 1) local branches and 2) remote branches.
[07:05] <poolfool> I just tried it out yesterday and followed /doc/'readme.html' ; but my big heart burn is it's (IMHO) ugly template language and fact that I can't modify index.tmpl.
[07:06] <james_w> poolfool: is there a directory named 'templates' in the cwd?
[07:06] <james_w> also what method are you using to run it?
[07:07] <poolfool> james_w: No, I have been editing ~/.bazaar/plugins/bzrweb/templates
[07:12] <poolfool> james_w: I am following the instrucitons from the 'readme.txt'; here is what I am doing http://pastebin.com/m52eb144c
[07:13] <poolfool> james_w: Then I edit the template ('~/.bazaar/plugins/bzrweb/templates/index.tmpl') and ... nothing?
[07:14] <poolfool> james_w: As a matter of fact the template has a heading level 1 <h1> that doesn't even show up ... so now I am not even sure it uses these templates.
[07:17] <james_w> right so if in the directory in which you run 'bzr webserve' you have a directory named 'templates' it will use what it finds in there.
[07:18] <james_w> if not then it will use '~/.bazaar/plugins/bzrweb/templates'
[07:24] <poolfool> james_w: Ok, I follow you ... but I don't think I am doing anyting wrong. I don't have 'templates' in the cwd or in the branch folder?
[07:25] <poolfool> james_w: So ... it should use the copy from '~/.bazaar/plugins/bzrweb/templates'?
[07:26] <james_w> poolfool: I think so.
[07:26] <james_w> you could try renaming the index.tmpl and see if it complains.
[07:29] <poolfool> james_w : Well, here is something else in the documentation http://pastebin.com/m59611c13 ; I think I will try 1) creating a 'templates' at cwd, 2) copy from default and 3) modifying index.tmpl
[07:34] <poolfool> james_w: Still no joy. I also tried 1) modifying index.tmpl and 2) '#bzr webserve --port=9099 "fool site" --templates ./templates ./test_repo'; Still no joy.
[07:37] <poolfool> LarstiQ: Do you have Godffredo's email address handy or is '@inwind.it" the best for now?
[07:39] <poolfool> mwhudson: Is loggerhead moving away from turbo gears?
[07:40] <mwhudson> poolfool: i'm thinking about ti
[07:40] <mwhudson> it
[07:40] <mwhudson> it brings some disadvantages and few advantages for an app like loggerhead
[07:41] <poolfool> mwhudson: Could you elaborate, or do you have a blog? Who pays you to work on loggerhead?
[07:42] <mwhudson> poolfool: i work for canonical
[07:45] <poolfool> mwhudson: Oohhh Michael Hudson. Well, I really do like loggerhead ... just might not be what I need right now. Thank you for your hard work ... bzr, loggerhead, ubuntu ... good stuff.
[07:52] <abadger1999> mwhudson: oh? What are the advantages and disadvantages?
[07:54] <mwhudson> abadger1999: well, the problems are mostly: cherrypy
[07:54] <mwhudson> it mangles urls in unhelpful and irrevocable ways
[07:54] <mwhudson> and does really odd things if there's an exception during url traversal
[07:55] <mwhudson> the benefits of TG are that it works and the pieces fit together nicely
[07:55] <Peng> Pylons? Django?
[07:55] <Alien_Freak> how do I fork off a branch in bzr?  ie,  i need to maintain a main repo, and have a secondary repo sync up to main repository
[07:55] <mwhudson> Peng: all overkill for the need at hand, really
[07:55] <Peng> I don't think hgweb uses anything. It's completely custom.
[07:55] <mwhudson> i'm tempted to redo it as SimpleHTTPServer with genshi templates
[07:56] <mwhudson> (it uses kid right now, which is another thing i dislike quite a lot)
[07:56] <abadger1999> Yeah -- we've found some of those things too.  One of our other devs is hosting a TG2 sprint to work on addressing some of those things as well.
[07:56] <mwhudson> abadger1999: cherrypy 3 looks a _lot_ better from what i can tell
[07:57] <mwhudson> shame that it's one of the few un-pluggable parts of TG1 :)
[07:57] <poolfool> mwhudson: bzr-webserve (hgweb) uses the built in python http object and extends it ... but I just don't get it.
[07:57] <abadger1999> TG2 is moving to pylons rather than cherrypy3, though.
[07:57] <poolfool> mwhudson: which would you take (if forced to) builting python http object or cherrypy 2 ?
[08:02] <fullermd> Alien_Freak: You probably mean 'branch' where you said 'repo'.  And the 'branch' command will do that.
[08:04] <Alien_Freak> does the branch have all the data that the main branch has?
[08:05] <fullermd> Yah.
[08:05] <poolfool> Alien_Freak: Um ... you are what I was about two weeks ago. Lots of good guys on IIRC here. Follow this old track between bignose and me http://pastebin.com/m32b3d220
[08:07] <Alien_Freak> thanks for link poolfool
[08:08] <GaryvdM> I pulled the latest bzr.dev
[08:09] <GaryvdM> When I bzr commit - it's saying that every file in the branch is modified
[08:09] <GaryvdM> So I did a bzr uncommit, and then a bzr status, and it correctly shows the changed files.
[08:10] <GaryvdM> And then did a bzr commit again , and again it say that every file is modified.
[08:10] <GaryvdM> Should I be worried about this?
[08:12] <jelmer> GaryvdM: what does the diff for the committed revision say?
[08:15] <james_w> GaryvdM: is it permissions or line-endings?
[08:16] <GaryvdM> Ah - I'm not sure what I have done with this tree now
[08:16] <GaryvdM> Let me start again
[08:18] <GaryvdM> Ok - first of all, when I commit there is an error (I did not notice this the first time)
[08:19] <GaryvdM> Traceback here: http://pastebin.com/m38f73166
[08:21] <GaryvdM> In the diff for the commited revision, there are files with properties changed.
[08:22] <GaryvdM> Is that permissions james_w?
[08:22] <GaryvdM> I guess I should send this to the mailing list?
[08:24] <fullermd> "properties changed" probably means +x (well, or -x)
[08:27] <james_w> GaryvdM: I would report that traceback as a bug.
[08:27] <GaryvdM> Ok
[08:59] <schierbeck> hi guys
[09:03] <KenB_> Anyone have a minute for a newbie Q?
[09:04] <jelmer> 'evening schierbeck
[09:04] <jelmer> KenB_: sure
[09:04] <schierbeck> hi jelmer
[09:05] <schierbeck> i've got an interesting patch on the list :)
[09:05] <KenB_> Thx,  I'm trying to figure out how to see what has happened recently in a network repository.  If I do:
[09:05] <KenB_> bzr diff -r branch:sftp:\\blah\blah
[09:06] <james_w> it should probably be sftp://blah/blah
[09:06] <GaryvdM> schierbeck: Hi
[09:06] <KenB_> [branch colon // s]  not smiley
[09:07] <KenB_> I get all the diffs on all the files that have been changed, which is too much.  What I want is something like status but referring to the network repos.
[09:08] <schierbeck> hi GaryvdM
[09:08] <james_w> KenB_: bzr status -r branch:sftp://blah/blah ?
[09:10] <KenB_> I tried that, but got an error - I send the error msg to bazaar@lists.ubuntu.com as requested.
[09:11] <james_w> KenB_: do you have lsdiff installed?
[09:11] <KenB_> I was thinking that perhaps bzr status -r submit: might work, but apparently submit: is only for diff
[09:12] <james_w> or diffstat.
[09:12] <james_w> if you have then doing 'bzr diff -r branch:... | lsdiff' or diffstat should tell you what files changed.
[09:12] <KenB_> james_w - no, are those plug-ins?
[09:12] <james_w> they are external to bzr.
[09:13] <jelmer> lifeless: so, looks like I'll end up working on bzr-git...
[09:13] <james_w> they are just normal command line tools.
[09:13] <KenB_> Oh, I get it.  yes, that might help a lot.
[09:13] <james_w> jelmer: as samba is going to use git?
[09:30] <jelmer> james_w: well, we'll be using git "on probation" for the next month or so
[09:30] <jelmer> but I really don't expect us to go back
[09:40] <ubotu> New bug: #149113 in bzr "KeyError: None when commiting" [Undecided,New]  https://launchpad.net/bugs/149113
[10:44] <hunmonk> question: does bzr use any kind of database to stored it's stuff?
[10:44] <hunmonk> if not, what format are the .knit files?
[10:45] <james_w> they are a custom format.
[10:48] <hunmonk> but not db driven?
[10:48] <james_w> no
[11:06] <lifeless> jelmer: samba ?
[11:16] <jelmer> lifeless: yes
[11:18] <lifeless> oh man
[11:18] <lifeless> thats pretty disappointing
[11:20] <jelmer> yeah :-/ performance and git-style repositories being the main reasons
[11:20] <LeoNerd> Define "database"
[11:20] <lifeless> what, all-branches-in-one-dir ?
[11:20] <LeoNerd> I could argue that the .knit files are a form of database.
[11:20] <lifeless> LeoNerd: they are
[11:20] <LeoNerd> They store data
[11:21] <jelmer> lifeless: yes
[11:21] <fullermd> Well.  My phone list (managed with vi and grep, the way $DEITY intended) is a form of database...
[11:21] <lifeless> LeoNerd: actually, knits are more analogous to tables in a db
[11:21] <LeoNerd> In such a DB that has tables...
[11:21] <lifeless> LeoNerd: we do :)
[11:22] <LeoNerd> I mean.. an LDAP directory is a database.. That doesn't have tables..
[11:24] <fullermd> all-branches-in-one-dir has some handy properties...
[11:24] <jelmer> especially for compiled projects
[11:26] <lifeless> jelmer: switch ?
[11:27] <jelmer> lifeless: doesn't work for non-lightweight branches afaik and still requires you to have a branch directory somewhere
[11:28] <lifeless> well, its a small patch to make it work, if its important, and I hadn't heard muttering
[11:28] <lifeless> and yes, its true you need a branch dir, but it can be ../a and ../b
[11:28] <jelmer> lifeless: It's not just being able to switch, also the fact that a repository (and all branches in it) can be copied easily, etc
[11:29] <jelmer> also, I'm just reporting what argumentation I heard, not necessarily what I'm missing in bzr myself (never really having using git)
[11:30] <lifeless> sure
[11:30] <lifeless> not meaning to shoot the messenger
[11:30] <lifeless> just trying to say that with closer dialogue these could have been addressed
[11:30] <fullermd> That's a handy thing on a large project.  I _like_ knowing my one step of cvsup'ing the FreeBSD repo gives me all the branches, and I don't need to care about them individually.
[11:30] <lifeless> having different ideas doesn't mean we want to be difficult to use for some projects
[11:32] <jelmer> lifeless: I know, but that still leaves a couple of other issues open (such as performance)
[11:33] <lifeless> is this a done deal for samba?
[11:33] <lifeless> or is there time to show the packs branch and the hpss streaming-fetch stuff?
[11:34] <jelmer> lifeless: for the time being, I think so - unless we'll hit problems within the next month or so
[11:34] <lifeless> well
[11:34] <lifeless> theres an insane git fanboyness happening at the moment
[11:35] <jelmer> there are still a couple of bzr fans within the team
[11:35] <lifeless> ok
[11:35] <lifeless> so what can we do?
[11:36] <jelmer> but at the moment, we can't do much else but admit migration to git is a better choice /at the moment/
[11:36] <lifeless> I see
[11:37] <jelmer> lifeless: *PERFORMANCE*, git-style repositories, parallel imports, nested trees
[11:38] <jelmer> (git has submodules now, which we may very well use)
[11:38] <lifeless> yes
[11:38] <lifeless> they seem to have done roughly our design for that
[11:38] <lifeless> integrated in the core, rather than a forest style thing built on top
[11:39] <lifeless> jelmer: have you tried out packs yet?
[11:39] <jelmer> lifeless: yes! They're a big improvement
[11:42] <jelmer> I mention parallel imports because different imports from svn and cvs not having the same revids hurt us while we were using bzr - one of the big advantages of git mentioned
[11:42] <lifeless> well
[11:42] <lifeless> you can always assign ids using the git algorithm
[11:43] <jelmer> doesn't that break referential integrity because it doesn't use any parent ids?
[11:44] <lifeless> huh?
[11:44] <lifeless> bzr's model allows commit builder to return the id
[11:44] <lifeless> this is put in for bzr-svn/bzr-hg etc
[11:44] <jelmer> yes, but you can't use the git algorithm there without problems, can you?
[11:45] <lifeless> what problems?
[11:45] <jelmer> I mean, since the git algorithm is purely content-based, it doesn't include parent ids and can those generate the same revid for two revisions with the same contents but different parent ids
[11:45] <lifeless> if you have all of history guaranteed, you can do that
[11:45] <lifeless> what do you mean by parent ids?
[11:46] <lifeless> do you mean file ids?
[11:46] <lifeless> or the ids of the parents of the commit?
[11:46] <jelmer> the revids of the parent revisions of the revision you're committing
[11:46] <lifeless> the git algorithm hashes though in the revision object's serialised form
[11:47] <jelmer> ah
[11:48] <jelmer> sorry, I misunderstood then
[11:48] <lifeless> you can't do this inside bzr's native serialisation format because to insert into the knit you need the revid, but if you leave the index pointers out
[11:48] <lifeless> and instead hash tree of the user supplied data alone, e.g. a bzr testament, then you can arrive at a hashed, including parent ids, content summary and use that for your revid
[11:49] <lifeless> then you batch insert all the data
[11:49] <lifeless> and it will work fine
[11:49] <lifeless> abentley: ping
[11:59] <lifeless> jelmer: so packs help; do they help enough ?