[00:00] i'm thinking the linux kernel is probably a little ambitious for the moment... [00:05] mwhudson: Banshee would work. That's ~20Mb or so of git. Or is that not medium enough? [00:05] RAOF: let's try it [00:05] RAOF: url me up? [00:05] Also has the advantage that I know bzr-git successfully branches it. [00:05] git://git.gnome.org/banshee [00:06] oh right, all the gnome imports [00:06] There's _lots_ of them available :). You don't want one of them? [00:06] libdrm would be another one. [00:07] RAOF: no, i'd just forgotten === UdontKnow is now known as \0 [00:09] mwhudson: linux should work well with dev6 [00:09] lifeless: until --default-rich-root is dev6 or similar... [00:09] (actually i think it will import into 1.9-rich-root now) === \0 is now known as root === root is now known as KnightWhoSaysNi [00:15] spiv: I'm a little worn on repeated 'cut a round trip off' day days [00:15] spiv: I had wanted to pair today, but my desktop blew a sprocket on saturday [00:15] spiv: so perhaps tomorrow? [00:16] lifeless: sure, tomorrow sounds good to me. [00:16] hi :) I recently stumbled over the following bug and reported it: https://bugs.launchpad.net/bzr/+bug/370551 Is there a chance that a fix will make it in a 1.14 maintenance release, or in 1.15, at least? [00:16] Launchpad bug 370551 in bzr ""bzr mv --auto" provokes traceback when auto detecting files that were moved to unversioned directories" [Medium,Confirmed] [00:17] bazaar cannot handle files that were moved to unversioned directories. but this makes the auto-detect feature more or less useless (for me, at least) [00:18] jonnydee1: thats a dupe actually [00:18] jonnydee1: no, 1.14 won't get a fix; its not a regression. You can just 'bzr add' the new directory before you move files into it, to avoid the bug. [00:20] bug 367628 [00:20] Launchpad bug 367628 in bzr "bzr mv unversioneddir/ fails" [High,New] https://launchpad.net/bugs/367628 [00:20] thats the root cause [00:20] lifeless: I know I can add the directory. But I need auto-detection when I refactor code using an ide. and there it happens often enough that files are moved to newly created directories.... [00:20] jonnydee1: in your example you manually move a file to the unversioned dir first [00:27] lifeless: and how do I recover from the stack trace if I occasionally got trapped by this bug? Will it suffice to 'bzr add' the unversioned directory, afterwards? [00:27] https://bugs.edge.launchpad.net/bzr/+bug/367628 is the main bug for 'bzr mv foo unversioned/' [00:27] Launchpad bug 367628 in bzr "bzr mv unversioneddir/ fails" [High,New] [00:27] The problem is that 'bzr st' does not work anymore, which makes it hard to figure out what directories are needed to be versioned... === abentley2 is now known as abentley [00:28] lifeless: ok, should I mark the other bug report as a duplicate? [00:28] no [00:28] it may be slightly different [00:28] I'm going to note that in the bugs [00:29] my browser just stopped working for a minute, doing that now [00:29] ok, thank you, lifeless, for your help :) [00:31] no problem [00:34] poolie: http://igotgenes.blogspot.com/2009/04/how-symbolic-on-removing-symlinks-in.html [00:35] hm that's good i guess [00:36] wbn if somebody fixed the bugs though :) [00:36] lifeless, poolie : will be nice to see you at UDS :) [00:39] you too === spm_ is now known as spm === abentley1 is now known as abentley === abentley1 is now known as abentley [01:54] spiv: wow, bug 250451 gets nastier and nastier [01:54] Launchpad bug 250451 in bzr "bzr suggests wrong URL for break-lock with a LP hosted branch" [High,Confirmed] https://launchpad.net/bugs/250451 [01:54] mwhudson: yeah [01:54] mwhudson: I suppose LP could monkeypatch sys.stdout to autocorrect that message ;) [01:55] spiv: we _should_ translate paths in some exceptions [01:55] but i don't think that will help here [02:09] ugh, how many times do i merge stuff from another branch, forget to commit, do a bunch of work, and realize now i have my merge changes all messed up with my new work [02:09] is there an easy way to fix that ? ^^ [02:12] shelve? [02:12] i've done a bunch of work, shelve will take me all night :( [02:13] shelve, redo the merge, commit, unshelve [02:13] ? [02:13] oh you mean shelve everything ? [02:18] What's with the alternating '>' and '<' in the pretty display when communicating with a remote server? [02:18] AfC: traffic direction [02:20] rocky: right [02:20] rocky: you'll might have to fix some conflicts when you unmerge, but hopefully not too bad [02:20] s/unmerge/unshelve/ [02:22] spiv: oh [02:22] Is there a way to turn off the progress bar and just have the textual information? [02:23] mwhudson: wow, conflicts are huge (like whole files) [02:26] AfC: not that I know of. [02:27] rocky: :( [02:27] actually it wasn't so bad [02:27] it was just one file like that and the fix was easy enough [02:27] so yeah i'm all set now. .. thanks mwhudson! :) [02:28] spiv: I recall we talked about that here a while back - I guess I need to file a bug for that. [02:28] rocky: np [02:28] mwhudson: although for what it's worth, after shelving my stuff i had to "revert" the bzr merge that wasn't being committed before i could start over [02:29] rocky: hm, that makes sense [02:29] * mwhudson wouldn't know how shelve interacts with pending merges, i guess it just ignores them [02:30] well, bzr doesn't know that something special has happened with shelve so bzr stat still shows the pending merge, just with no changes [02:30] and you can still commit the pending merge with no changes [02:30] but obviously you don't want to, so just rever it [03:02] http://3x3cut10n3r.mybrute.com/ <-- have fun & good luck [03:11] jelmer: are you going to be at uds? === abentley1 is now known as abentley [07:07] hi all [08:04] signing off [08:04] gnight [08:08] hello vila! [08:09] good bight lifeless, hi poolie [08:09] err night [08:14] vila, what are you working on next? [08:14] bug #366107 [08:14] Launchpad bug 366107 in bzr "Bazaar should attempt Basic authentication if HTTP server offers NTLM" [Undecided,Confirmed] https://launchpad.net/bugs/366107 [08:15] surprisingly, we can't handle servers which propose several auth schemes :-/ [08:16] then I'd like to refactor log tests and dig there, several bugs are hanging around since last Ian optimisations [08:17] I'm also waiting for a review related to bug #355454 to finish fixing it [08:17] Launchpad bug 355454 in bzr "$ make check-dist-tarball failure" [High,Fix released] https://launchpad.net/bugs/355454 [08:22] hm ok [08:23] 366107 sounds like a good thing to fix but i'm not so sure it's high priority [08:23] is it easy or already something you want to fix? === jamesh_ is now known as jamesh [08:24] poolie: should be easy once I enhance the related test servers and I'd like to fix it as not being able to handle server with multiple auth schemes is a bit embarassing :-} [08:27] ok [08:27] you probably know best [08:28] do you have an order of magnitude guess how long the log tests and fixes would take? like a week? [08:30] surely less, it's first: refactoring existing ones that checks for particular revisions to avoid depend of the actual output format, then add new ones for the bugs I know of (mostly wrong selection of revisions) [08:38] meh --coverage fails to recognize code run in threads :-/ [08:43] vila: that's probably not too hard to fix [08:43] vila: add a call to threading.settrace in apply_coveraged in bzrlib/commands.py, probably [08:47] spiv: works, great, thanks :) [09:02] vila: just in case you're curious, i'm adding support for multiple byte ranges to twisted's http server currently :) [09:04] mwhudson: good, feel free to canibalize our http_server, there are some subtleties in parsing and validating the ranges requested [09:05] vila: no kidding [09:05] :) [09:07] vila: twisted already had a pretty anal parser and handled the single-range case [09:09] mwhudson: you may also want to have a look at lp:~vila/bzr/local-test-server for a quick way to validate your server against bzr === serg_ is now known as serg [09:57] hi guys! anybody home? [10:00] I have a little question about English word "control" from "version control system". When you say "control" there you mean "management" or "check" or "watching"? [10:02] I'd say management [10:02] hi luks [10:02] hey [10:02] how are you? [10:02] fine, thanks. you? [10:02] more or less [10:03] thanks for explanation [10:03] well, that's just my opinion [10:03] my question raised because we have incorrect translation in Russian of this term [10:03] and how I'd translate it to another language [10:04] I understand [10:05] translation in Russian is wrong because we have the word "control" here too, but it's false friend of translator [10:05] Russian control it's closer to "check" [10:05] same here in slovak [10:06] :-) [10:07] I've started heavily using "daggy fixes" in my work [10:07] this very heavily influencing my style of work with VCS [10:08] I don't think I could strictly follow that [10:08] maybe for recent branches [10:08] but definitely not for something old [10:08] well, in my case I need to maintain several branches in parallel, so it's work OK [10:08] and for old branches too [10:08] my mileage is different I suppose [10:09] well, I'm a lazy person :) [10:09] me too, but daggy fixes make my life easier [10:09] because cherrypick in bzr sometimes painful [10:10] the only feature I like in svn better [10:10] cherrypick? [10:10] yep [10:13] IIUC this is inevitable downside of DAG-based systems [10:14] exactly [10:15] bialix: I'd say that the "control" part of VCS isn't terribly significant. [10:15] hi jml [10:15] jml: why not? [10:15] bialix: "management" is close enough, I guess. [10:16] thanks [10:16] bialix: but when I hear the phrase, I think "version $GENERIC_VERB $GENERIC_ABSTRACT_NOUN" [10:16] version handler thing [10:16] :-) [10:17] ok, one more question: when you say "version" and "revision" -- what's difference? [10:17] VCS vs RCS [10:17] not much. [10:17] "version" has a connotation of "released version", I guess [10:17] version is more genric term? [10:17] yeah. [10:18] "revision" almost always refers to the result of a commit (in IT, anyway.) [10:19] I read "revision" as in "document revision" [10:19] right, that's the broader sense [10:19] it's about editing the text, is not? [10:19] a revision is what you get after you have revised something, usually a text. [10:20] i.e. when I fix some errors in the text? [10:20] yeah. [10:20] or improve something? [10:20] thanks [10:20] the things much clearer now [10:21] it's so hard to translate VCS terms adequately [10:21] I'll bet! [10:21] doesn't russian have a commonly used equivalent? [10:22] that's the problem [10:22] we have some de0facto equivalent [10:22] de-facto [10:22] but sometimes they are represent svn-centric point of view [10:22] i.e. you have no pull/push in svn [10:22] Revision is a bad term for VCS because it's colloquially used to mean a diff and the result of applying a diff. [10:23] I think the the term applies to any vcs [10:23] davidstrauss: what will be better? [10:23] bialix: commits should be called snapshots [10:23] so if there were some manuals for csv or something, I'd use the term from there [10:23] *cvs [10:24] bialix: commits/revisions used to not be atomic, so you couldn't call them snapshots [10:24] luks: well, there is semi-official translation of svn [10:24] "svn book" [10:24] bialix: but any modern vcs has atomic commits, so we ought to call them snapshots [10:24] davidstrauss: but we don't :) [10:24] is not "commit" is the action [10:25] ? [10:25] but snapsot is the object [10:25] bialix: See, that's another troublesome term [10:25] depends, git uses it as the result of the action [10:25] bialix: "Commit" can be the action of committing or the snapshot produced by committing [10:25] nice [10:26] bialix: "Snapshot" is so unambiguous, I can even use it to define the confusing VCS terms. [10:27] I agree here [10:27] bialix: It's a nice metaphor, too [10:27] but it's not very translatable, I guess [10:27] bialix: git could not call it a snapshot, though, because they have the staging area [10:27] I can't think of a slovak translation for shapshot [10:27] for those who like photography? [10:28] luks: What is the translation used for file system snapshotS? [10:28] for me snapshot is more about photo [10:28] davidstrauss: I don't think there is one [10:28] http://en.wikipedia.org/wiki/Snapshot_(computer_storage) [10:28] we just use an expression to explain it [10:29] can't think of a direct translation [10:29] There are a few translations there in the inter-language links [10:30] three words for russian :) [10:30] It's pretty much impossible to find terms that work across languages. Computer terms are either metaphorical or made up [10:30] so the same problem, I guess [10:31] ah, no [10:31] luks: I'm sure "commit [10:31] luks: in russian it's called "phot of file system" [10:31] luks: I'm sure "commit" and "revision" are at least as bad [10:31] davidstrauss: definitely [10:31] I always laugh at the translation of commit in svn manuals [10:31] push is bad too [10:31] luks: At least "snapshot" is unambiguous and tangible to English speakers [10:32] luks: in russian svn book "revision" called an "editing" [10:33] it's so crazy [10:34] davidstrauss: "git could not call it a snapshot, though, because they have the staging area" -- I disagree [10:34] their staging area is also "snapshotting" [10:34] bialix: git isn't snapshotting anything [10:34] really? [10:34] bialix: http://fourkitchens.com/blog/2009/02/03/importance-atomicity-or-why-git-staging-area-bad [10:35] looking into .git directory I see they're store actual state of the files [10:35] davidstrauss: they are just applying a filter before they take the snapshot [10:35] luks: no [10:35] but I think it still is a shanpshot [10:35] luks: nope [10:35] luks: "Along these lines, one of the most atomicity-busting aspects of git’s staging area is that it doesn’t just mark code that needs to go into the next commit; it actually saves the hunk into the staging index. So, a developer could add code to the staging area, modify her working copy, and end up with a commit containing code that’s neither in her working copy nor in her stash." [10:36] luks: Something can be in the git staging area but not in your working copy. [10:36] hm, I didn't know that [10:37] luks: It's uncommon for someone to stage a change, revert it, and then commit the staged change, but it's quite possible. [10:37] davidstrauss: roughly the same happens in interactive darcs commit [10:37] luks: So, I think that violates the snapshot metaphor. [10:37] davidstrauss: if you define it as a tree-level snapshot, yes [10:38] you mean the staging area is virtual, but real files are real? [10:38] bialix: I mean a snapshot should be of your working tree [10:38] I understand [10:38] but... [10:38] but the same thing applies to svn then [10:38] bialix: A data structure that you stage changes into doesn't translate well to the snapshot metaphor [10:38] luks: no [10:39] see! even in English you can use snapshot differently [10:39] luks: svn allows selective commit, but the commit must be of files as they are in your working tree [10:39] davidstrauss: they might be out of date [10:39] davidstrauss: svn will automatically merge, if possible [10:39] luks: svn requires you to update prior to commit if you're committing to changed files [10:39] you can commit a revision that doesn't represent your working tree [10:40] sure, but it doesn't have to be the modified files [10:40] source code files usually depend on each other [10:40] luks: if you mean "merge" different directories, then yes, svn sort of violates it. but the problem is more that svn doesn't distinguish between branches and directories. [10:42] luks: svn takes snapshots from the directory you're in and below. [10:42] anyway, it's way past my bedtime [10:42] luks: I rag plenty on svn/git in that blog post, anyway [10:43] luks: And I do bring up that very issue [12:19] I think I'm missing something about bzr add. I have a clearcase view where I do updates to. I have created a bzr repo here and I do an bzr move --auto, bzr add then I was hoping to do a commit. However I do a bzr status and it shows a lot of files and directories as unkown with a ?. I expected the bzr add to add these files. What am i missing? [12:27] Jemsquash: have you done 'bzr init' at any point? if not I'd be expecting bzr mv and bzr add to be erroring [12:27] Jemsquash: if they aren't erroring, perhaps you are invoking 'bzr add' in a strange way? [12:28] I am just typing bzr add. [12:28] what does it report? [12:28] I have 3 revisions in the branch so it is definitely initialised. [12:28] nothing. [12:29] I do bzr add. The command completes with no response. I then do bzr status and it lists a load of files as unknown. [12:30] I initially did an add and it seemed to add a bunch of files, but seemed to leave a whole lot out. [12:30] would it be possible to pastebin? [12:30] bzr st [12:30] bzr add [12:30] bzr st [12:30] oh, actually [12:30] I think I know [12:30] if the things that are not getting added are all bzr trees themselves, that is why [12:30] what does 'bzr info ' report? [12:31] I can't do it here, it was at work today and I don't have access to irc from there. Corporate firewalls :( [12:31] I bet that the things you are adding are bzr trees,or perhaps svn or some other vcs that you have a bzr plugin for installed [12:31] I'm a bit lost when you say that things not being added are all bzr trees themselves. [12:32] Ok - perhaps. [12:32] I'll have an investigation into looking for .svn folders or .cvs folders. It is a possibility although I will be surprised. [12:32] to demo now [12:32] cd /tmp [12:32] bzr init foo [12:32] cd foo [12:33] bzr init bar [12:33] bzr add [12:33] bzr st [12:33] you should see that bar hasn't been added [12:33] yep. That sort of makes sense. [12:33] Is that due to the shared repo containing branches etc? [12:34] no, its because we haven't finished the nested trees support [12:34] ah ok [12:34] if it were to add bar, it would be versioning a link to bar, like a svn external [12:35] I'm not sure I want to understand this concept of nested trees. [12:35] heh [12:36] it sounds scary :) [12:36] its pretty straight forward; you have a bzr tree for a library or something that you want to embed in a larger tree [12:37] so the tree in effect is a project with subprojects in a way. [12:38] yes [12:38] If you created a branch from a branch that contained a nested branch would it copy that nested branch with its revisions across too? [12:39] I'm confusing myself with recursion when I reread my own post. [12:41] I guess I'm asking what the relevance of the link is vs the actual full blown nested repository. The link is versioned not the nested repo. [12:42] If I commit a change to the nested tree will it change the revno of the containing branch? [12:43] anybody knows approx timeframe for 1.15 release? [12:45] the relevance is that you can continue working on the subproject separately [in an entirely different machine, without the parent project, for instance], then pull across into the subproject dir where you are nesting it [12:45] if it was a new project, you've have to be doing merges, and it would be less conveninet [12:45] bialix: sorry, not offhand [12:45] well, when UDS then? [12:49] OK I think I understand. I would have to try it out to figure out how to use it. It sounds promising provided the overall project is structured correctly to cope with subprojects. [12:53] Thanks for your suggestion on checking to see if the unadded files & directories are themselves under revision control. [12:56] UDS will be 25-29 May. So I suppose 1.15 will be before or after. right? [12:57] bialix: I'm not exactly sure; I'd ask the list if you need to know [12:57] ok [13:58] hi, i need to upgrade my branch to "rich-root-pack" to use split, right? [14:05] phanatic: yes [14:05] mwhudson: yes [14:07] jelmer_: thanks. bzr upgrade --rich-root-packs should do the trick, right? [14:09] phanatic: if you're restricted to bzr <= 1.0, yes [14:09] phanatic: (1.9-rich-roots also exists, for example) [14:10] jelmer_: any ideas why i get this: http://pastebin.com/d37856392 ? [14:10] phanatic: you must upgrade the repo, not the branch [14:11] ah, thanks :) [14:46] I'm trying to find an easy way of migrating from clearcase to bazaar. I've come across a tool that will migrate from clearcase to subversion. I could then import into bazaar from there. The tool that I found can be found at http://community.polarion.com/index.php?page=download&project=svnimporter Does anyone have any better suggestions in migrating to bazaar? === vxnick_ is now known as vxnick === dereine[OFF] is now known as dereine [16:22] Jemsquash: I don't know about clearcase->svn, but svn->bzr is pretty easy. [16:23] The only thing I can think of is that you might lose some metadata in the clearcase->svn migration. [16:23] SVN doesn't do non-linear history. [18:00] hi [18:02] I have a question? any german people? [18:23] the informations of an branch like history.. are they stored in the branch or in the repository folder? [18:30] limor: The history is stored in the repository. [18:31] limor: All .bzr/branch contains is some meta data and a pointer to the branch's tip revision, which can be used to reconstruct the history from the repository. [18:37] ah ok so the branch .bzr folder only store the metadata an the .bzr in the repository filder stores the history where the branch points to [18:51] I'm attempting to use loggerhead to view a remote svn branch, does anyone know if this should work? === KnightWhoSaysNi is now known as BlackKnight [18:51] I am trying for example ./serve_branches svn+http://svnserver/repos/trunk [18:53] mrooney: That's an interesting idea. [18:53] mrooney: does serve-branches load plugins? [18:53] james_w: Yeah. [18:53] It tells me "... is not a directory" though. [18:54] do I need some switch to tell loggerhead it is a remote branch? maybe it has nothing to do with bzr-svn? === beuno_ is now known as beuno [18:57] From the file/class names, it seems filesystem-centric. [18:57] mrooney: serve-branches serves all branches under a directory, so that's probably not going to work [18:58] oh darn and the repository doesn't work either [18:59] I already have a full svn import of the repository, maybe I should add a commit hook to update it and then I can just use the local bzr thing [18:59] although I bet it would be useful to others as well if it could work the aforementioned way [18:59] yep [18:59] loggerhead can do it fine [19:00] just serve-branches can't set it up in the right way it seems [19:00] is the other launch script still there? [19:00] start-loggerhead I think it was [19:00] or does serve-branches say anything about a config file in the source? [19:00] hi guys [19:00] no config file for serve-branches (yet) [19:01] oh okay it works fine on my import [19:01] but it doesn't have the fancy ajax expanding of changes or the unified diff / side by side toggle [19:01] does LP have its own version or do I need trunk? [19:01] mrooney, trunk has those [19:01] ah ok let me grab that [19:01] LP uses trunk [19:01] fancy :) [19:02] we like cutting edges :) [19:03] could I ask for your (collective) advise on something? [19:03] is it possible to use bazaar in the following way: I have a container folder which represents the complete project. Within this folder there are container subfolders representing a part (e. g. a DLL) of the project. Does bazaar recognise this project layout in the way that it knows that the subfolders are parts of the project container? [19:03] hmm it looks the same to me [19:03] I will take a look later [19:04] mrooney: I think I know [19:04] mrooney: loggerhead tries to store a cache in the branch [19:04] mrooney: and that might rely on local file access [19:04] beuno: ^ [19:05] jelmer_, it does [19:05] well [19:05] not *in* the branch [19:05] in a /tmp dir [19:05] beuno: oh, ok [19:05] although, tbh, I don't know what it would do with remote branches [19:05] beuno: so that doesn't explain why ./serve-branches doesn't work [19:06] lifeless and I tried it on SVN branches locally, and it owrked [19:06] jelmer_, right. Other than "I have never tried that" :) [19:06] it theory, it *should* work [19:06] what's the best way to deploy an app to a server with bzr? At the moment I'm using bzr-upload from my dev machine to the server itself, but I'm now wanting to centralise things so I can have a repository view on my project management system. [19:07] beuno: serve-branches:47 has a check that the specified path is a directory :-) [19:07] jelmer_, ah. There you go [19:07] because we do directory navigation [19:07] as well as branches [19:08] I guess we need a different path when it's already a branch [19:08] beuno: directory navigation could be done using Transport though [19:08] beuno: Transport.list_dir works on svn transports [19:08] jelmer_, interesting. May work better. [19:08] I guess that would be a bug [19:09] vxnick_, you could use push-and-update [19:09] and block .bzr dir from being served [19:09] beuno: thanks - does that push to the central server and then update the remote production server? [19:09] vxnick_, pushes and updates the working tree in the remote location [19:09] you need ssh [19:10] thanks, I'll take a look at its docs [19:10] welcome' [19:10] Would using transports hurt Loggerhead's performance on local branches? [19:11] Peng_: it would have a very slight overhead [19:12] BTW, Loggerhead does support remote branch references. [19:12]