[02:04] howdy, anyone know if I can get bzr status to work non-recursively, i.e. to not report on child directories? [02:09] toddw: bzr st `find . -maxdepth 1 ! -type d` [02:09] toddw: I think adding a --no-recurse option to bzr status would be a reasonable feature request. [02:09] spriv: nod, what about windows :D [02:10] spiv: thanks, I'll make the bug request [02:10] toddw: cygwin ;) [02:11] oders [02:11] * ericvw wrong window [02:17] toddw: a use case would be good too [02:17] toddw: because all the times I've seen someone want that so far, its really been a svnism [02:18] heh, it's for a GUI that does only wants to show the status of a particular directory [02:22] I'd much rather guis use the scriptable interfaces - [02:22] ls, xmlrpc, or plain python [02:23] I'd also ask *why* the gui wants to only know one directories status [02:24] nod, I don't know a lot on the scriptables, does that require the GUI to provide their own install of bzr? [02:25] no [02:25] the reasoning here - status is for humans, we will continually adapt it to make it more useful [02:26] GUI's that are generating data should depend on programmatic interfaces that are less subject to make-it-pretty changes [02:26] as for doing one dir vs the whole tree [02:26] its much more efficient to do the whole tree once than to call into bzr once per directory [02:26] (and I mean _MUCH_ more efficient) [02:27] is there info on these scritables part? [02:27] yes [02:28] the IntegratingWithBazaar wiki page talks about the xmlrpc interface used by bzr-eclipse and other IDE's [02:28] the bazaar pydoc/pydoctor API documentation talks about using the python interface directly, and there are examples on th ewiki [02:37] there is an additional plugin to provide xmlrpc, does not seem that friendly - additional step(s) [02:37] or use the python bzr library files, which sounds good, but I'm guessing I'd need to find both the library files and the correct python installation to run it [02:38] honestly, the --non-recursive command line option is looking much simpler for me [03:09] Oh look, another project doing a source control vote between hg and git... [03:11] fullermd: whom [03:12] Dragonfly[BSD] [03:12] Git seems to be leading about 2:1 [03:14] Right up top of http://news.gmane.org/gmane.os.dragonfly-bsd.kernel/ === cafuego is now known as buggerror === buggerror is now known as cafuego [04:28] any idea when a bzr-svn update to correspond to bzr 1.8 is due out? [04:37] uniscript, 0.4.13 works with 1.8 [04:38] so why did the bzr update from ppm push out bzr-svn? [04:38] uniscript, ppa hasn't been updated yet [04:38] for bzr-svn? [04:39] yeah [04:39] OK, any idea when? [04:39] I want my bzr-svn back :) [04:39] no, sorry [04:39] ah so I should get the source package and change the depends and rebuild [04:39] OK [04:41] jam usually does the ppa uploads, not sure what his plans are [04:42] is he uk TZ based? [04:42] uniscript: yeah, or alternatively you can install the debian experimental package [04:42] US based [04:42] package built [04:43] aah build failed ah well time to add ppa to pdebuild :) [05:33] jelmer: how goes 0.5, BTW? [05:34] I never sent you an update on those Unicode exceptions, BTW, because I couldn't reproduce them with the current top of tree [05:34] jelmer: also, in the event of a catastrophic "you screwed up", doing a Subversion repository dump and re-import, with a filter to leave out the bzr-svn properties, should allow a clean start, right? === jaypipes is now known as jaypipes-afk [07:10] hi all [07:18] * fullermd waves vila. === AnMaster_ is now known as AnMaster [09:33] hi vila [09:34] hi ! === sabdfl1 is now known as sabdfl_epic [10:52] hi the happy community [10:52] can you give me a link to a nice doc that compare bzr and git? [10:53] you can't find anything objective [10:54] ok [10:54] is there a doc that explain big changes between CVS/svn and bazaar ? [10:54] ace: are you already a Bazaar user? [10:54] no [10:54] i m a CVS/SVN user for 8 years [10:54] ace: tell you what, then. Why don't you just use Bazaar, and then you won't have to worry about comparing it to Git. [10:55] and i want to discover what make bazaar so different and better before using it :) [10:55] That's one way to shortcut documentation :p [10:55] fullermd: I thought so, yes [10:55] ok i ll continue to googlize then [10:55] ace, which one do you want to win the comparison? If you want git to win, go to the git site and if you want bzr to win got to the bzr site :) [10:56] lol [10:56] it really depends what is important to you [10:56] Which one wins if you go to the darcs site? [10:56] ace: have you read Bazaar's user manual? Why don't you start with that. [10:56] afc: i ll do that [10:56] fullemd - mercurial of course! [10:56] Blast their sneaky liquid metal hides! [10:59] btw here's my take given a dev team here just went from svn -> git -> hg (I wonder how long before the see real sense) [10:59] svn is centralised, yawn. git is fast, powerful and nearly unusable, [10:59] uniscript: why unusable? [10:59] hg doesn't have hgpushsvn which makes it useless if you want to work with an svn repo [11:00] too hard to setup? [11:00] what is hg? [11:00] the strikes against git are: revisions are all shar hashes and auto tagging is a pain [11:00] hg is mercurial [11:00] ah ok [11:00] why hg? [11:00] mercurial is perceived to be nice on windows due to tortoisehg [11:00] there s no H nor G in mercurial [11:00] which is a gtk application ;) [11:00] why there can't be one big tortoise project with plugable backends I have no idea [11:01] ace: Check your periodic table of elements :p [11:01] aaahhhh lol they are crazy [11:01] so ease of use and model goes to bzr [11:01] integration with svn goes to bzr [11:02] speed still doesn't go to bzr but it's getting better [11:03] I *like* bzr it just feels right [11:03] the rest all seem to be that you are working around stuff [11:03] if you are workign on the kernel, you will have to use git [11:03] as I say, it all depends on what is important to you [11:03] ace: Hg is the chemical symbol for mercury [11:03] LeoNerd: yes i understood :) [11:03] i have a big source tree, bzr will be too slow? [11:04] big is pretty relative [11:04] how big is big? [11:04] ace: unless your big is >>> Mozilla, no, it'll be fine. [11:04] Also depends on what way the big is. [11:04] I've used bzr on trees of 4,000 HTML and Perl files. That worked just fine. [11:04] Hellofalotquicker than the CVS that used to run it [11:04] Long histories are where bzr really eats itself. Large trees with lots of files, not so hard. Very large files, hard again. [11:05] let me check [11:05] * fullermd considers "big" to start at a hundred thousand revs of a hundred thousand files. [11:06] 5000 Cpp sources ode for a total of 60mb of text files [11:06] ace: that's tiny. [11:06] ok [11:06] you won't have performance issues with that tree and bzr [11:06] perfect then [11:06] not even if the tree grows 4x [11:06] you will only have the usual startup performance issues :) [11:07] The ones that really blow my mind are the Apache mob. They have *all* projects in a *single* Subversion repository. It has over 700,000 revisions in it. Gadzooks. [11:07] AfC: kde too [11:07] AfC: why exactly is that bad? [11:07] it just really constrains your options [11:07] Well, it's not by itself; only after you point bzr-svn at it :p [11:08] mwhudson: Oh yeah? Haven't tried to import any KDE code lately :) [11:08] it's about the same size i think, ~750k revisions [11:08] that's the price for abusing svn :) [11:08] s/ab// [11:08] if you use it the svn way, it's fine [11:09] luks: well, for one thing, it means several hundred completely unrelated projects are entirely dependent on a single on disk structure. [11:09] luks: Another is that it means they are all contending for unique resources (the primary key problem). [11:09] AfC: that's a problem apache sysadmins have to consider, not you [11:09] luks: Third is, well, "HELLO, no bloody way am I putting my precious source code in a single point of failure like that!" [11:09] :) [11:09] luks: see point 3 then :) [11:09] Well, and that's the sort of load and use-case svn is designed to push for. [11:10] i would have recommended a more granular structure [11:10] yeah. [11:10] makes it just that much easier to reconfigure, rearrange [11:10] teaches better coding practice! [11:11] sabdfl_epic: actually, it's not true [11:11] but would have required more thought and possibly more sophisticated project infrastructure [11:11] one big svn repository is much more flexible [11:11] * fullermd gets all snarky at the thought of "better coding practice" and "java and XML everything"... [11:11] fsvo flexible [11:11] moving history from one repo to another is a pain [11:11] ... but you know the Apache mob mindset. Not even "Our way or the highway" because they tend to just focus on "Our way" [11:11] with a single repo you can rename/move anything [11:12] I personally use svn the same way [11:12] it's just easier [11:12] does svn not provide a facility for nested trees through externals? [11:13] Well. Nice jamming with you lot. Time to get out for a drink. [11:14] That's not the only use case. Take splitting off a part of a project into a new project of its own; in one big repo, you can do that with svn. You can't, with the same capability, do it with bzr at all. [11:14] fullermd: that's true. The join/fork story here could be a lot nicer. Alas. [11:15] Yeah. Your choices are either (a) throw away all the history, (b) drag along a lot of unrelated history, or (c) recreate a mirror of the history (which may or may not be sufficiently easy, but still breaks all previous and future merging across the boundary) [11:17] It CAN'T be done as simple as svn, internally. And it would take a lot of infrastructural work and papering to make something functionally equivalent work reasonably well. [11:17] (which isn't bzr-specific at all of course. git or hg or anybody else who conceptually works in full trees would have the same issues) [12:00] if I move my branches, how do I make my checkouts point to the new location? [12:03] Personally I'd vim .bzr/branch/branch.conf [12:06] bzr bind blah [12:06] That doesn't fix up all the locations though... push/missing etc [12:11] vila: hello! === Verterok|out is now known as Verterok [12:26] jml: bzr switch, possibly with --force, if I'm understanding the question correctly? [12:28] mwhudson: hi ! [12:28] spiv: probably [12:29] jml: (or edit .bzr/branch/location manually, assuming these are lightweight checkouts...) [12:33] spiv: thanks. [12:36] vila: Ng would like to talk to you, i hope :) [12:38] btw, if anyone is curious, bzr on a largish tree in an encrypted filesystem is basically unusable. [12:41] jml: lifeless would be, I bet [12:42] vila: it's about bzr's http requests [12:42] * vila listening [12:42] if I see this in a .bzr.log..... [12:42] 22.384 * About to connect() to squid.internal:3128(proxy for bk-internal.mysql.com) [12:42] 22.384 > GET http://bk-internal.mysql.com/bzr-mysql/.bzr/repository/packs/4390f40920ca612296692194f5c6235d.pack [12:42] 22.385 > Host: bk-internal.mysql.com [12:43] is that *exactly* what was sent? ie there was no HTTP/blah after the URL? [12:43] the request looks like HTTP/1.1, but afaik if you don't *say* HTTP/1.1 you may not get it, and in this case it's not [12:44] What that produced with -Dhttp ? [12:44] yes [12:44] urlib or pycurl ? [12:44] how would I determine that? [12:45] nm, if it's .bzr.log it's urllib, sry [12:45] the puller forces urllib [12:47] Ng: Ok, relevant line is 517 in _urllib2_wrappers and indeed is restricted to method and url, so the don't worry, the right headers should be send, but if you used -Dhttp, you should see that too in .bzr.log [12:48] But if you're observing the whole file being transfered instead of just the range requests, there is a known bug in Squid, what version are you using ? [12:48] vila: 2.6.18 [12:49] and for the first part of the question ? Did I guess right ? [12:54] vila: I'm not exactly sure, bzr just seems to hang [12:55] Can't remember the squid version it was fixed in, spiv and lifeless knows it by heart I'm pretty sure... [12:55] hang for how long ? What size is the pack file ? [12:55] it's 8MB, it hangs for about 10 minutes and then says: InvalidHttpResponse: Invalid http response for http://bk-internal.mysql.com/bzr-mysql/.bzr/repository/packs/4390f40920ca612296692194f5c6235d.pack: Expected a boundary (squid/2.6.STABLE18:CDF2964E12A3A3AF0D83A580AC47D079) line, got '' [12:56] Yeah, sounds like it, I'm still searching the relevant bug report, sorry for the delay [12:56] np [12:57] Yeah, I remember that one... [12:58] bug 198646 maybe? [12:58] Launchpad bug 198646 in squid "Invalid http response ... Expected a boundary" [Medium,Fix released] https://launchpad.net/bugs/198646 [12:59] * vila was thinking about putting fullermd inside ubottu seconds ago :) [12:59] > This was fixed in the 2.6.STABLE19 release [...] [12:59] fullermd: yeah ! Well done [12:59] It's always one version more than you have ;) [13:00] Ng: as fullermd said ^ [13:00] * fullermd has validated his oxygen consumption for the day! [13:00] Ng: upgrade your squid and you should be fine [13:01] vila: ok thanks very much [13:01] Or if you have access to use sftp/bzr+ssh, so you don't hit squid. [13:01] fullermd: thanks too :) [13:02] Ng: have a look at the bug report anyway as there are some more explanations [13:02] yep, am reading it :) [13:03] I think I'll celebrate by dredging up a sandwich, and then getting back to the eternal joy of writing documentation... [13:07] hi all [13:08] some3kksf: Hi? [14:53] tell me, does "bazar" means something in english? [14:54] ace: http://www.thefreedictionary.com/bazar [14:54] funny [14:56] ace: It stems from "The Cathedral and the Bazaar" by esr. [14:57] ah ok [14:57] it has sense === SteveA_ is now known as SteveA === jaypipes-afk is now known as jaypipes [15:46] do directory services have a way of influencing what directory name is created when you don't specify one to "bzr branch"? [15:55] james_w, afaik not [15:56] it doesn't look like from the code [15:56] oh well [16:22] I'm getting an error: [Errno 1] Operation not permitted [16:23] Is there a way to run bzr in verbose/debug mode? [16:23] I tried -v and --verbose with no luck. [16:24] NfNitLoop: try -Derror [16:25] NfNitLoop: and "bzr --version" will tell you where your log file is located, that will have more information [16:27] actually, a bit of googling found my exact error (and solution): [16:27] https://bugs.launchpad.net/bzr/+bug/183948 [16:27] Ubuntu bug 183948 in bzr "can't PUSH over an sshfs fuse file share" [Undecided,Won't fix] [16:28] it's an issue with sshfs, not bzr. [16:30] -orename? [16:45] Hi ? Is it possible to get from bzr only conflictin file names ? [16:47] matkor: bzr conflicts? [16:47] vim $(bzr conflicts --text) [16:48] james: Great ! Thanks a lot that's what I am looking for [16:52] https://bugs.launchpad.net/bzr-fastimport/+bug/287785 is there a way to assign that bug to me or so? [16:52] Ubuntu bug 287785 in bzr-fastimport "bzr-fastexport crashed in git-bzr -- broken pipe" [Undecided,New] [16:53] I'm not really sure how launchpad works [16:53] Pieter: yeah, there is [16:53] oh, I found the drop down thingie [16:53] yup [17:13] i was working bound to a repo, did a few local commits, then when I was back online, I did a bzr update, and it deleted a bunch of files. How can I get back my files that were in my local commits? [17:21] evarlast, bzr help revert [17:22] but revert to what? [17:22] also, does bzr work ok with rbash instead of regular bash? [17:22] bzr log shows only server revs, not my local commits. [17:22] evarlast, i don't know, hence why i said use bzr help revert [17:22] i'm not psychic [17:22] i do not know what revisions had the files that got deleted [17:22] o_O [17:22] If you install the heads plugin, you can use it to find the revid of your old local commit head. [17:22] ooh [17:22] ok, so new question driven by spaz, how can I revert to a local commit or see them in logs. [17:22] see fullermd's comment ^ [17:23] Then you can merge it in. [17:23] wow, so I need the heads plugin to see local commits in the log? [17:25] That's... too narrow and too broad to answer. [17:25] seems like I should be able to bzr log --local or something. [17:25] When you update with local commits, they should be turned into pending merges. Various things you can do from that point (including revert) can lead to them being off in never-never land. [17:25] No, 'local' doesn't really mean anything special in this case. [17:26] There's only log, and log works backward from a head. Those revisions aren't in the history of your current head. [17:26] it did when I bzr commit --local, didn't it? [17:26] Not exactly, no. [17:26] oh, so I should move my current head? [17:27] But the revs are still in your repository. The heads plugin lets you find unreferenced revs in the repo, so once you find the revid, you can force your head to change to that, or merge it in, or whatever is appropriate. [17:27] Sorry I can't do details; I'm way overdue to be off elsewhere :| [17:28] ok, I have heads, but the guy with the real problem doesn't :( [17:29] Local commits are a treacherous corner. When you do them, you're working in a distributed fashion, with a layout that works in a centralized fashion. There are a lot of dragons in a setup like that. [17:30] strangely, he did commit local, then he did bzr up, and I would expect them to be pending merges, but bzr status doesnt' show them as such [17:38] so how to restore the old dead head? [17:41] i've got a dead head, but I want files out of it. [17:51] ah, the nastly long revid: from the heads list. [17:52] thanks. [17:52] special thanks to Spaz and fullermd [17:58] np [18:22] fullermd: heads is part of bzrtools nowadays. [18:47] Hi, what command does bzr smart server run? [18:47] I can't figure out what force command to set in sshd_config [18:48] to disallow anything except bzr [18:48] it runs `bzr server --inet ...` [18:49] luks, and what extra parameters after that? [18:49] um, I don't know [18:49] AnMaster, probably whatever command the client asked is my guess [18:49] there is a wrapper script which might be easier to use for this [18:49] Spaz: no [18:49] luks, oh? got a link? [18:50] luks, I guess it would need repo path [18:50] `bzr serve --inet --allow-writes --directory=/` would be my guess [18:50] AnMaster: it's in contrib/ in the tarball [18:50] contrib/bzr_access [18:50] hm, installed from ports on freebsd so that means *looks at launchpad branch* [18:50] AnMaster, no [18:50] you can have per-repository permissions [18:51] AnMaster, cd /usr/ports/devel/bzr; make fetch; make extract; cd work/ [18:51] Spaz, more complex [18:51] though i suppose that's like killing a bird with a boulder [18:51] also build tree not same as ports tree [18:52] aye it is [18:52] but would be faster ;P [18:52] launchpad is slow atm [18:53] "Sorry, there was a problem connecting to the Launchpad server." [18:53] at http://bazaar.launchpad.net/~mbp/bzr/bzr.1.8/files [18:53] someone forgot to feed the hamsters powering the server [18:53] * AnMaster sighs [18:53] ah works now [19:32] is the main difference between branches and repositories that repositories are branches without a working tree? [19:35] RaceCondition: repositories are containers for branches, nothing more [19:35] they allow for efficient data sharing for related branches [19:35] can repositories be worked in, i.e. do they have a working tree? [19:35] (e.g. branches with a common ancestor) [19:36] and does the data sharing efficiency only come into play when all branches in the repository are on the same machine/disk? [19:36] no, again, repositories store branches, period [19:36] branches have working trees [19:36] yes, I know that [19:36] I'm trying to draw parallels to other VCS's [19:37] And yes, the savings are realized for the branches stored in a particular repository [19:37] so in which real life situations I would use a repository? [19:37] You should always use one! [19:38] You should use many in fact, typically one per project [19:38] to store your local branches for said projects [19:38] why not just use branches? [19:38] anytime you plan on storing related branches, you should put them in a repository, to gain the efficient storage benefits [19:38] I mean, what's the benefit of having branches in a repository as opposed to having them stand alone? [19:38] storage efficiency [19:38] other than that [19:39] none that I am aware of [19:39] by efficiency, I mean mostly disk space [19:39] yeah [19:39] which could potentially significantly improve speed, because disk access is slow [19:40] I'm not aware of what format bazaar uses for repositories though.. I know git stores everything in files so it can simply use hardlinks when cloning a repository [19:40] RaceCondition: Bazaar uses packs [19:40] indeed [19:40] and hard links are support as well [19:40] but not used by default, I believe [19:40] are packs modified or are they immutable? [19:41] RaceCondition: But using repositories in Bazaar is more that all the branches inside it use the same packs, not that the packs are copied as hardlinks [19:41] but if hardlinks are possible, why are repositories used? sorry for so many questions, I'm just trying to get the picture here [19:41] RaceCondition: Bazaar objects are immutable, just like git objects - packs are not immutable in either Bazaar or git [19:42] are packs stored as multiple files then or as a single file? [19:42] RaceCondition: Packs are stored as one or more files [19:42] And may be repacked [19:42] I see [19:43] The main advantage of a shared repo in Bazaar is that branches do not copy the entire repository when you make a new one [19:43] so basically achieving the same thing git does with hardlinks using a different approach [19:43] indeed, creating a branch stored in a repository inside the same repository is nearly instantaneous; it's great :) [19:44] git is also pretty instant because a branch starts off as one 40 byte file [19:44] why are most commands kinda slowish though? Python environment start up overhead? [19:44] RaceCondition: Which version and platform are you using? [19:44] and how many plugins [19:45] (and which) [19:45] Yes, also relevant [19:45] awilkins: I'm actually the most confortable using darcs but I've lately started using git because of it's speed and large community/tool support [19:45] but I really hate that it's unintuitive and is very hard to learn [19:45] I'm a programmer and consider myself a good learner, but git really gets me by the balls sometimes [19:46] Ah, I've been there as well. I could never figure out git entirely, bzr was very easy to pick up in comparison. [19:46] Here, "bzr st" takes less than a second in a reasonable size tree (870 items) (win32, core2duo 2gb, vista, bzr 1.8) [19:46] There are other advantages. Being in Python makes it easily hackable and readable (something shared by Mercurial). [19:46] well most commands are instantaneous in git :) [19:46] which I really enjoy [19:47] And I work on Mac OS X mostly, so directory versioning is critical. [19:47] I think you are right in thinking a lot of that is down to VM setup [19:47] Try "bzr shell" and see if that makes an appreciable difference to you [19:47] jfroy|work: I work on OS X, too, but why is directory versioning critical on OS X? [19:47] I think so too. Python takes a while to being up. [19:47] Because of bundles, executable ones or otherwise. [19:48] Frameworks, applications, document formats, plugins, are all directories on Mac OS X, and I appreciate that bzr handles them properly. [19:48] The advantages of Bazaar for me are i) It was easy to learn ii) It's fast (was faster than SVN, now is very fast) [19:49] iii) OK for my _users_ to learn [19:49] iv) Written in a language that I could be productive in without a major learning effort [19:49] indeed, the small learning curve makes it really easy to switch to. [19:49] so back to repositories -- when doing distributed development, should each developer have a repository or should there be one or more central/main repositories per project and developers just branch remotely from that (or from each other)? [19:49] jfroy|work: you are an OS X developer? [19:50] RaceCondition: You should have a central repo, and your own repo [19:50] I presume you did read it, but the bazaar guide presents a number of use case scenarios that are really great starting points. [19:50] RaceCondition: I work for Apple, so yeah :p [19:50] awilkins: so multiple repos and multiple branches per repo? [19:50] RaceCondition: more like, a project is going to have a set of branches [19:50] RaceCondition: Since you can push a branch to any repo (that has the same rich-root-ness!), yes [19:50] Some of those branches you will want to share, some will be private (each developer can have their own set of branches) [19:50] jfroy|work: cool, I like your products :P and now I know who to ask from when I can't figure out the directory layout of OS X :) [19:51] All of those branches will, likely, have common ancestors. [19:51] Yes, I find the combo of a no-trees repo and lightweight or heavyweight checkouts, plus switching, to be the most productive [19:51] So, you will want to setup one, or more, repositories on networked machines to share branches among developers. [19:51] ah, yeah, there are checkouts, too :P [19:51] And each developer will want one, or more, repositories to store branches they are working on on their own machines. [19:51] Does that make sense? [19:51] Checkouts are branches, with some convenience tossed on top of it. [19:52] so basically all developers have repositories plus central ones and all repositories contain all public branches of all developers + private branches? [19:52] Not necessarily. [19:52] well more or less [19:52] Repositories contain the branches that have been created in them or pushed to them. [19:52] Central repo doesn't have to have developer branches [19:52] repository is a (partial) map of the world (development status) of a single project [19:53] Correct, it will be a sub-set of all the branches. [19:53] yeah, I see [19:53] In almost all cases. [19:53] so in most cases, branches are never stored outside of repositories? [19:53] There will usually be a "mainline" or "trunk" branch, as well as "release" branches, in one, designated, central repository. [19:53] yeah [19:54] That central repository is not special in any ways, it is simply "designated" or "marked with a post-it note" as being the central repository. [19:54] RaceCondition: I end up with standalone branches where I'm just using Bazaar as a deployment mechanism :-) [19:54] yeah, good point [19:54] e.g. on user machines. [19:54] but, in theory, one could only use branches and never use repositories? [19:54] for development, that is [19:54] Yeah, I have a bunch of standalone branches for small stuff. [19:54]