[00:30] Hi. Some friends and I are looking at creating an opensource project, but we need a version control system which is easy to use and will work on either Sourceforge or the google code hosting thingy. We have narrowed our choices down to bazaar and SVK, is there any advice or extra info you can give that will help us come to a decision? [00:36] SF and google code both use subversion [00:36] you could use bzr-svn to interface if you want [00:36] or launchpad.net offers project hosting === pickscrap1 is now known as pickscrape [00:39] but launchpad.net isn't under GPL [00:40] which would be easier to use? bzr-svn or SVK(which I think has a svn interface) [00:42] is google code GPL'd? [00:42] Nyad: why does launchpad need to be under GPL? [00:42] is it still free? [00:42] it's always been free afaik [00:43] tnx [00:44] Nyad: launchpad's license doesn't affect your code's license [00:44] you can license your code however you want [00:44] I think it does require and open license though [00:45] well we are opting for GPL or LGPL so that should be fine [00:45] lamalex: I don't think it requires it, but the fact that your code will be online implies it [00:45] Pilky: not necessarily, it could restrict modification/redistribution [00:46] true [00:48] so it's actually possible to put your source up but say nobody is allowed to modify it or spread it? but then can't people just port it and make their own version from the source? [00:48] no, that'd be modification [00:48] which you disallowed [00:49] so they'd be violating your licence :) [00:49] yeah, but in all fairness, how well do licences stand up in court [00:49] closed licences better than open :) [00:50] best way to prevent modification is to keep your source closed [00:53] thanks === RAOF_ is now known as RAOF [02:00] * dennda just created a bug report for that sftp issue [02:01] https://bugs.launchpad.net/bzr/+bug/234682 <-- Do you feel like there's anything missing? [02:01] Launchpad bug 234682 in bzr "bzr fails in combination with ssh" [Undecided,New] [02:03] Your upgrade to 1.4, which includes a fix for that? O:-} [02:04] fullermd: Oh, it is fixed in 1.4? [02:04] https://bugs.launchpad.net/bzr/+bug/213425 [02:04] Launchpad bug 213425 in bzr ""'SSHSubprocess' object has no attribute 'get_name'" with paramiko > 1.7.2" [High,Fix released] [02:04] Does using curl provide any benefit over urllib? [02:04] Yah. Paramiko 1.7.2 and later changed somethingorother; 1.4 and later have the update. [02:05] bzrtools 0.91.0?! [02:05] fullermd: When will 1.4 be released? [02:05] dennda: A month ago :) [02:05] I don't want to use the old paramiko version through the cheeseshop [02:05] Oh [02:05] why isn't it in the repo yet :/ [02:05] Apparently the Arch maintainers aren't big bzr users? [02:06] 1.5 was actually released a week ago... [02:14] hi, i've got some questions about developping with bzr [02:17] what would be the easiest way to work with bzr in ruby ... i have seen some python wrapper for ruby so I would be able to import bzrlibs or to call system commands and parse the output from stdout .. or making a python application that makes xml or some others things that are easy to parse with bazaar as a backend [02:30] orphe, you do have an xml plugin for bzr [02:40] benuo : no but it would not be a problem to install... (such plugin exists) ? [02:41] beuno: no but it would not be a problem to install... (such plugin exists) ? [02:43] orphe, bzr-xmloutput [02:43] I use it for PHP, Verterok uses it for Java :) [02:45] ow man , that will be alot easier than I tought. Thank you! this is really something interesting. [02:47] with this i would still have to call bzr process but if I cache things until the repository is modified i would accelerate the process [02:50] beuno, thanks that's a really good thing. [02:53] orphe, no problem. Let me know if you need any more help on that, or if we can make your life easier with any feature [02:53] the project's on Launchpad, so feel free to open bugs [02:57] beuno, yes thank you again. [10:46] * _moshez waves [10:46] <_moshez> a friend of mine sent a q to the ml (https://lists.ubuntu.com/archives/bazaar/2008q2/042391.html ) but got no answer :( [10:46] <_moshez> can anyone take a look and see if there's help? [10:47] hi _moshez [10:47] I'm travelling atm [10:49] <_moshez> lifeless: hello I squish your tummy [10:49] lifeless, 0 hours! [10:49] liw: excellent [10:49] _moshez: hello, I am squished! [10:49] <_moshez> lifeless: also, if you could take a look at the question, I would be happy [10:49] <_moshez> lifeless: though it would not stop the squishing :) [10:49] _moshez: short answer: you can register a dynamic hook which is a closure rather than a global [10:49] _moshez: closures are love [10:50] _moshez: or, you can refactor cmd_pull to better separation of UI and code, so that you can decorate the deeper guts rather than having to deal with the return value which is (deliberately) appropraite for shell evaluation [10:50] <_moshez> also dynamic hooks are strange [10:51] <_moshez> lifeless: yeah, we were kind of scared of actually touching bzr code [10:51] I think some refactoring and a patch to mainline would be best [10:51] <_moshez> lifeless: awesome I'll see what I can do about it :) [10:51] its pretty nice python I think, few people seem to have trouble doing cosmetic changes [10:51] <_moshez> lifeless: I think I'll get him to go on irc... [10:52] <_moshez> lifeless: not scared of the source, scared of the process :) [10:52] I will be flapping shortly [10:52] meh, its much lower entry cost than twists penultimate perfect quality thingy [10:53] a) write code. b) send patch via 'bzr send --mail-to bazaar@lists.canonical.com [10:53] c) profit! [10:54] <_moshez> lifeless: *hugs* [10:54] <_moshez> lifeless: so far, as a company, we have not written twisted patches either [10:54] <_moshez> lifeless: we don't have corporate experience contributing to free software :( [10:54] _moshez: ah! [10:55] Ve have vayz of making you kode! [10:55] <_moshez> lifeless: the problem is more between sending the patch and having it in a bzr version, we'd be afraid to use our own bzr [10:55] do you mean your own build? [10:56] <_moshez> lifeless: yeah [10:56] <_moshez> lifeless: we should probably wait for, ironically enough, moving to ubuntu from fc6 for that [10:56] so if you have a plugin, you'r running your own build :P [10:56] if you see what I mean [10:56] <_moshez> lifeless: distribution of plugins is easier [10:57] anyhow, fortunately bzr runs from a working tree trivially [10:57] <_moshez> lifeless: when we use ubuntu on developer desktops, it'll be easy to distribute custom builds [10:57] you only need one custom instance tho - the integration manager right ? [10:57] <_moshez> lifeless: probably [10:57] :P [10:57] <_moshez> lifeless: also the integration mgr actually already uses ubuntu [10:57] excellent === ubottu is now known as ubott2 [10:58] <_moshez> lifeless: so far, it looks like we'll be going for the dynamic hooks solution === ubott2 is now known as ubottu [10:58] patching pull would likely be better long term [10:58] <_moshez> lifeless: we intend to improve the integration mgr anyway, I'll possibly refactor pull then [10:58] <_moshez> lifeless: if we do it now, it would delay the move-to-bzr project [10:59] <_moshez> which I really really want to do ASAP [10:59] * _moshez does the "yay bzr" dance [10:59] also,i fyou are doing non trivial business logic, consider working with the bzr domain objects directly [10:59] much richer scripting interface [10:59] * lifeless does the yay adopters dance [10:59] <_moshez> lifeless: url for documentation of that? [10:59] pydoc bzrlib.branch.Branch etc [10:59] oror pydoctor [11:00] also doc/developers [11:00] <_moshez> lifeless: ah. we do that a little too in "surrounding bazaar" scripts [11:00] <_moshez> like our build downloader, which generates a mail after reading the bzr ci log :) [11:00] are you liking bzr? [11:01] liw: 0 hours -> done, or 'nearly'? [11:01] _moshez: did you see my 'scaling test' blog post? [11:01] <_moshez> lifeless: no :( [11:01] <_moshez> url me [11:01] http://planet.bazaar-vcs.org/ [11:02] lifeless, when you check your e-mail, you'll find the location from which to copy :) [11:02] lifeless, (iow, done) [11:06] liw: most excellent [11:06] tell me now, I will start it coping in DC [11:07] is it the for-lifeless dir? [11:09] damn, tungestem only has 1.3G free! [11:09] lifeless, that's the dir, yes [11:10] cool [11:10] copying to manganese [11:11] _moshez: pretty cool if I do say so myself huh? [11:13] I just ran bzr check for fun, and it says KnitCorrupt! :( [11:14] An SHA-1 doesn't match. [11:14] Some revision from bzr.dev from 2005, so it's not like I've lost data. [11:14] interesteing [11:14] what format repo? [11:15] Packs. [11:15] ...And wow, it sure floods .bzr.log. [11:15] plain, not rich root? [11:16] Plain, AFAIK. [11:16] bzr info -v :) [11:16] Yeah, plain. [11:17] ok, thats .. interesting [11:17] is it a mismatc on the inventory, or a file text? [11:18] Inventory. [11:19] mumbe [11:19] mumble [11:20] we should track this down, but not from an airport lounge. [11:20] perhaps you could file a bug / ask a question in lp ? [11:21] But tracking down version control consistency errors is what airports are for! [11:21] Mailing list? [11:21] or that [11:22] How active is the LP questions thingy vs. the list? [11:23] should be similar in terms of folkl witht he knolwdge needed to drill into this [11:25] Peng: I see the same thing here, on bzr.dev [11:25] KnitCorrupt: Knit inventory corrupt: [11:25] sha-1 a7b104d9ee824caed0e59a2989446419e230c4c2 [11:25] of reconstructed text does not match [11:25] expected 873bfb499cc42b19241ac60c9736568abe2e4518 [11:25] for version mbp@sourcefrog.net-20051027032619-323471e9b77bd69a [11:26] Peng: you see the same one? [11:26] sabdfl: Different revision for me, john@arbash-meinel.com-20051117204806-013b3027c63d642b [11:26] iiiinteresting [11:26] ok, definitely file a bug on this [11:27] we have to identify whats going on here as a priority [11:27] sabdfl: Wait a minute. How did your check not take half an hour to run? [11:27] if its statically bad, then there is already a bug open about why this is not detected outside of check; if its creeping bad find-and-fix [11:28] lifeless: What do you mean? If it's not consistent which revision it claims is bad? [11:28] Peng: as it happened, i started the same check an hour ago, on a whim :-) [11:28] i was interested to see how long it would take [11:28] sabdfl: Um, wow. That's a heck of a coincidence. [11:28] Peng: actually, he rooted your box and watched you doing check [11:28] Peng: but he'll never admit to it [11:28] :) [11:29] :-p [11:29] so I had a scare when I got to singapore [11:29] sabdfl = super-user accounts breaking daemon for lifeless? [11:29] at the transfer desk, when the agent mutters and mumbles [11:29] and you ask 'is there a problem', you don't want them to say 'you are not booked on that flight' [11:30] ( https://answers.launchpad.net/bzr/+question/33093 is similar.) [11:33] lifeless: and he said? [11:33] 'you are not booked on that flight' [11:34] I have a seat, and apparently luggage etc should be ok, and they haven't asked for a credit card, but something *whacky* is going on [11:36] OK, it should die soon. [11:36] (I'm running check again.) [11:37] BTW, it was about the first versionedfile it was checking, according to the progress bar. [11:43] Hi, I have a serious problem with bzr 1.5 (and tool 1.5.0 as packaged in Debian): some commands, like commit, just hang indefinitely. [11:44] and if I break them with C-C then the tree is broken. even status reports an internal error. [11:44] fog: if you hit ctrl-\ it will drop you into pdb [11:44] there is obviously something wrong but I cna't help you right now - sorry. [11:45] lifeless: thanks, I'll try to debug it myself. [11:45] Ok, "bzr checked" died again. Same revision. [11:45] if noone else can please gather what info you can and file a bug/post a message to the list [11:45] -> QF6 to sydney :) [11:45] lifeless: Still want me to file a bug? [11:45] Peng: yes [11:46] lifeless: Will do. [11:46] lifeless: Have a good flight. :) [11:47] <_moshez> lifeless: so I was going to mention that it would be nice if people would get responses to mail [11:47] <_moshez> lifeless: it used to be the problem with twisted, btw, that you could only get the information if you were on irc :( [11:48] _moshez: most mails get answers; you can tell from the archives [11:48] _moshez: but most of the core devs are not volunteers, and tend to do other things in weekends [11:49] really gone [12:16] Y'know, the spinner in the progress bar is kind of bad over ssh. [12:19] is anybody using a checkout for putting changes onto launchpad, but using a branch to do most of their dev work? [12:19] because I'm just thinking about how to do the merging and such... am I right in thinking that you can't push to a checkout [12:20] Try it. [12:20] If you push to a checkout, I think bzr will push to its parent. [12:20] hmm [12:20] I don't use checkouts at all, except for the occasional lightweight checkout, but even then only rarely. [12:21] well I'm thinking of me and my friend each having personal branches, plus the checkout of the central repo [12:21] when we want to put something onto launchpad we merge into the checkout and then commit [12:22] I'd use a branch and merge, commit, push. Shrug. [12:22] yeah, we're just finding some problems with that with us both working on the same branch [12:24] What problems? [12:25] lots of conflicts and such, just seems to be a bit more awkward [12:27] I saw it mention using a checkout for putting stuff into launchpad and a separate personal branch for doing most of the editing in the launchpad docs and thought it sounded like it would work better [13:27] heya === [PUPPETS]Gonzo is now known as ^Gonzo^ === Pilky_ is now known as Pilky [14:00] Howdy, I thought I could "bzr init-repository ", do "bzr init " in and then bzr push bzr+ssh://..+junk/myrepos, guess not eh? [14:00] can only push a branch, not a repository? [14:00] gumpa: indeed [14:01] thanks [14:03] Hello, apparently bazaar only partially supports end of line conversion. isn't this bad if we have developers from different OS using bazaar for our project? [14:04] depends [14:04] if everyone uses an ok editor, it won't matter [14:05] for source/text files, at least [14:06] so basically all our editors must use the same end of line ascii characters. but that would restrict us to not being able to use any editor [14:06] no, not at all [14:06] you just need an editor that ill sue whatever a file already uses [14:07] er "will use" [14:07] why hasn't bazaar added this end of line conversion? [14:07] but a cvs-esque feature for bzr is under development [14:10] doing it cleanly is hard, and no one has done it yet (well, not had it merged into mainline) [14:11] so if we start our project with the windows ascii value for end of lines then kate and wordpad will keep it that way? [14:13] never used kate, but I would be surprised if it didn't [14:14] ok tnx [14:14] wordpad coul have problems [14:14] which would you say is easier to use, bazaar or SVK? [14:14] with windows line endings? [14:14] yes [14:14] bob2: ah, sorry [14:14] bzr for sure [14:14] svk will get upset if you move a checkout [14:15] The only options are bzr or svk? [14:16] for us, we narrowed it down to those two [14:16] why not hg as well? [14:17] never heard of it [14:20] You should have. [14:20] how does it compare to bazaar and SVK? [14:20] or is it not really important which we use? [14:24] I like both bzr and hg. They both have their upsides and downsides and IMO it's a toss-up. I've never used svk and don't plan to. [14:25] ok thanks. I have to go now [14:25] I will look into hg [14:31] Oops. [14:31] haha [14:31] "Hello, welcome to #bzr. You should try out hg!". [14:32] I got yelled at a bit for that once. :\ [14:33] I'm just not very brand-loyal. [14:33] I think it's important to just be honest and to recommend whatever sems best in the situation [14:33] seems [14:33] Which is obviously ClearCase. [14:35] In this case, hg does have line ending conversions, based on globbing the file path. [14:38] not quite sure how the line endings are that big a problem unless you use a crap text editor [14:40] It's nice to set that "just to be safe". When one developer uses a weird editor just once and doesn't notice, it makes a bit a mess of history. [14:41] true [15:34] 3 [15:35] oops ,w/w sorry [17:16] Peng: i saw you saying that bzr check is slow for you. it's fast for me. what are you comparing it to? [17:17] sabdfl: I just mean vs. "hg verify". [17:17] are you sure they do the same level of analysis? [17:19] sabdfl: hg verify is so fast that I doubt it does much of anything. [17:19] then it would seem unfair to criticize bzr for doing a rigorous job ;-) [17:19] :) [17:26] can I remove files from a repository ? [17:41] visik7: bzr remove [FILES...] [17:42] add --keep to the end if you don't want the files deleted on disk [17:44] Pilky: from a shared repository not from a branch [17:45] I've removed from a branch but the shared repository still contains the files [17:45] visik7: I think if you push to the shared repo it will remove it [17:46] mmm no [17:46] Umm... it can't. [17:46] I've erroneously versioned 200mb of jpeg [17:46] Half the point of revision control, is that you can check out an earlier point in history [17:46] and now they are in the .bzr of the shared repo [17:46] So that data has to remain in the repo [17:47] What I suggest you do is create a new branch that cherrypicks the old one, and don't include the revision that added that file [17:47] Then you'll be left with a new branch that has "holes" in the history; that one file never existed. You can then push this new branch back over the old one [17:48] oh, you were wanting to remove the actual file [17:59] I imagine this is one of those usual "I want to pretend this file never existed" situations.. [17:59] Usually they come up either by someone adding/commiting a file of secrets (keys, passwords, etc..) or from just adding really big junk files [18:57] oww.. printing out the full tree is not a very useful debugging message [20:14] is it possible to get a 'bzr stat'-style difference between branches? 'bzr status -r ../../criss/' gave me this error: http://pastebin.ca/1029096 [20:29] grantgm: bzr help revisionspec [20:29] * Peng leaves. [20:44] right. i meant bzr status -r branch:../../criss/ [20:44] that should work, no? [20:51] what d= [20:51] output would you expect? [20:53] as i said, i was looking for a bzr stat between two different branches [20:54] but it errors out (full message in at http://pastebin.ca/1029096) [20:54] yes, but what should it show? what if both have changed a file? or just one? [20:56] well, i would expect it to use the directory given as the old one, and the current directory as the new. Thats the convention, right? [20:57] So if there was a difference between the files, it would be under 'changed', regardless of which branch made the change [20:57] not for stat [20:57] you can do a bzr diff between the two [21:00] I guess I don't understand what the -r arg does for stat, then. [21:01] Can I get diff to just show me which files have changed, rather than the actual changes? [21:01] thats really what I'm looking for. stat just seemed to be the most obvious way to do so [21:02] thanks for the help, btw [21:04] hmmm...looks like this is a known problem: https://bugs.launchpad.net/bzr/+bug/144421 [21:04] Launchpad bug 144421 in bzr "Using branch: revspec in stat blows up" [Undecided,Confirmed] [21:13] bzr diff --old=../../criss --using=diff --diff-options="--brief" [21:14] fwiw, that seems to do essentially what I'm looking for [21:43] how can I resolve a directory conflict ? [23:05] lifeless, when you deprecated get_revision_graph in 1.4, what would be the way to do it now? === mwhudson is now known as mwh === mwhudson_ is now known as mwhudson [23:59] morning [23:59] hello [23:59] hi poolie [23:59] hello [23:59] Good morning. [23:59] morning everyone