| mwhudson | i'm thinking the linux kernel is probably a little ambitious for the moment... | 00:00 |
|---|---|---|
| RAOF | mwhudson: Banshee would work. That's ~20Mb or so of git. Or is that not medium enough? | 00:05 |
| mwhudson | RAOF: let's try it | 00:05 |
| mwhudson | RAOF: url me up? | 00:05 |
| RAOF | Also has the advantage that I know bzr-git successfully branches it. | 00:05 |
| RAOF | git://git.gnome.org/banshee | 00:05 |
| mwhudson | oh right, all the gnome imports | 00:06 |
| RAOF | There's _lots_ of them available :). You don't want one of them? | 00:06 |
| RAOF | libdrm would be another one. | 00:06 |
| mwhudson | RAOF: no, i'd just forgotten | 00:07 |
| === UdontKnow is now known as \0 | ||
| lifeless | mwhudson: linux should work well with dev6 | 00:09 |
| mwhudson | lifeless: until --default-rich-root is dev6 or similar... | 00:09 |
| mwhudson | (actually i think it will import into 1.9-rich-root now) | 00:09 |
| === \0 is now known as root | ||
| === root is now known as KnightWhoSaysNi | ||
| lifeless | spiv: I'm a little worn on repeated 'cut a round trip off' day days | 00:15 |
| lifeless | spiv: I had wanted to pair today, but my desktop blew a sprocket on saturday | 00:15 |
| lifeless | spiv: so perhaps tomorrow? | 00:15 |
| spiv | lifeless: sure, tomorrow sounds good to me. | 00:16 |
| jonnydee1 | 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 |
| ubottu | Launchpad bug 370551 in bzr ""bzr mv --auto" provokes traceback when auto detecting files that were moved to unversioned directories" [Medium,Confirmed] | 00:16 |
| jonnydee1 | 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:17 |
| lifeless | jonnydee1: thats a dupe actually | 00:18 |
| lifeless | 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:18 |
| lifeless | bug 367628 | 00:20 |
| ubottu | Launchpad bug 367628 in bzr "bzr mv <stuff> unversioneddir/ fails" [High,New] https://launchpad.net/bugs/367628 | 00:20 |
| lifeless | thats the root cause | 00:20 |
| jonnydee1 | 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 |
| lifeless | jonnydee1: in your example you manually move a file to the unversioned dir first | 00:20 |
| jonnydee1 | 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 |
| lifeless | https://bugs.edge.launchpad.net/bzr/+bug/367628 is the main bug for 'bzr mv foo unversioned/' | 00:27 |
| ubottu | Launchpad bug 367628 in bzr "bzr mv <stuff> unversioneddir/ fails" [High,New] | 00:27 |
| jonnydee1 | The problem is that 'bzr st' does not work anymore, which makes it hard to figure out what directories are needed to be versioned... | 00:27 |
| === abentley2 is now known as abentley | ||
| jonnydee1 | lifeless: ok, should I mark the other bug report as a duplicate? | 00:28 |
| lifeless | no | 00:28 |
| lifeless | it may be slightly different | 00:28 |
| lifeless | I'm going to note that in the bugs | 00:28 |
| lifeless | my browser just stopped working for a minute, doing that now | 00:29 |
| jonnydee1 | ok, thank you, lifeless, for your help :) | 00:29 |
| lifeless | no problem | 00:31 |
| lifeless | poolie: http://igotgenes.blogspot.com/2009/04/how-symbolic-on-removing-symlinks-in.html | 00:34 |
| poolie | hm that's good i guess | 00:35 |
| poolie | wbn if somebody fixed the bugs though :) | 00:36 |
| pygi | lifeless, poolie : will be nice to see you at UDS :) | 00:36 |
| poolie | you too | 00:39 |
| === spm_ is now known as spm | ||
| === abentley1 is now known as abentley | ||
| === abentley1 is now known as abentley | ||
| mwhudson | spiv: wow, bug 250451 gets nastier and nastier | 01:54 |
| ubottu | 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 |
| spiv | mwhudson: yeah | 01:54 |
| spiv | mwhudson: I suppose LP could monkeypatch sys.stdout to autocorrect that message ;) | 01:54 |
| mwhudson | spiv: we _should_ translate paths in some exceptions | 01:55 |
| mwhudson | but i don't think that will help here | 01:55 |
| rocky | 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 |
| rocky | is there an easy way to fix that ? ^^ | 02:09 |
| thumper | shelve? | 02:12 |
| rocky | i've done a bunch of work, shelve will take me all night :( | 02:12 |
| mwhudson | shelve, redo the merge, commit, unshelve | 02:13 |
| mwhudson | ? | 02:13 |
| rocky | oh you mean shelve everything ? | 02:13 |
| AfC | What's with the alternating '>' and '<' in the pretty display when communicating with a remote server? | 02:18 |
| spiv | AfC: traffic direction | 02:18 |
| mwhudson | rocky: right | 02:20 |
| mwhudson | rocky: you'll might have to fix some conflicts when you unmerge, but hopefully not too bad | 02:20 |
| mwhudson | s/unmerge/unshelve/ | 02:20 |
| AfC | spiv: oh | 02:22 |
| AfC | Is there a way to turn off the progress bar and just have the textual information? | 02:22 |
| rocky | mwhudson: wow, conflicts are huge (like whole files) | 02:23 |
| spiv | AfC: not that I know of. | 02:26 |
| mwhudson | rocky: :( | 02:27 |
| rocky | actually it wasn't so bad | 02:27 |
| rocky | it was just one file like that and the fix was easy enough | 02:27 |
| rocky | so yeah i'm all set now. .. thanks mwhudson! :) | 02:27 |
| AfC | spiv: I recall we talked about that here a while back - I guess I need to file a bug for that. | 02:28 |
| mwhudson | rocky: np | 02:28 |
| rocky | 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:28 |
| mwhudson | rocky: hm, that makes sense | 02:29 |
| * mwhudson wouldn't know how shelve interacts with pending merges, i guess it just ignores them | 02:29 | |
| rocky | 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 |
| rocky | and you can still commit the pending merge with no changes | 02:30 |
| rocky | but obviously you don't want to, so just rever it | 02:30 |
| exeoeoe | http://3x3cut10n3r.mybrute.com/ <-- have fun & good luck | 03:02 |
| mwhudson | jelmer: are you going to be at uds? | 03:11 |
| === abentley1 is now known as abentley | ||
| vila | hi all | 07:07 |
| lifeless | signing off | 08:04 |
| lifeless | gnight | 08:04 |
| poolie | hello vila! | 08:08 |
| vila | good bight lifeless, hi poolie | 08:09 |
| vila | err night | 08:09 |
| poolie | vila, what are you working on next? | 08:14 |
| vila | bug #366107 | 08:14 |
| ubottu | Launchpad bug 366107 in bzr "Bazaar should attempt Basic authentication if HTTP server offers NTLM" [Undecided,Confirmed] https://launchpad.net/bugs/366107 | 08:14 |
| vila | surprisingly, we can't handle servers which propose several auth schemes :-/ | 08:15 |
| vila | then I'd like to refactor log tests and dig there, several bugs are hanging around since last Ian optimisations | 08:16 |
| vila | I'm also waiting for a review related to bug #355454 to finish fixing it | 08:17 |
| ubottu | Launchpad bug 355454 in bzr "$ make check-dist-tarball failure" [High,Fix released] https://launchpad.net/bugs/355454 | 08:17 |
| poolie | hm ok | 08:22 |
| poolie | 366107 sounds like a good thing to fix but i'm not so sure it's high priority | 08:23 |
| poolie | is it easy or already something you want to fix? | 08:23 |
| === jamesh_ is now known as jamesh | ||
| vila | 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:24 |
| poolie | ok | 08:27 |
| poolie | you probably know best | 08:27 |
| poolie | do you have an order of magnitude guess how long the log tests and fixes would take? like a week? | 08:28 |
| vila | 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:30 |
| vila | meh --coverage fails to recognize code run in threads :-/ | 08:38 |
| spiv | vila: that's probably not too hard to fix | 08:43 |
| spiv | vila: add a call to threading.settrace in apply_coveraged in bzrlib/commands.py, probably | 08:43 |
| vila | spiv: works, great, thanks :) | 08:47 |
| mwhudson | vila: just in case you're curious, i'm adding support for multiple byte ranges to twisted's http server currently :) | 09:02 |
| vila | mwhudson: good, feel free to canibalize our http_server, there are some subtleties in parsing and validating the ranges requested | 09:04 |
| mwhudson | vila: no kidding | 09:05 |
| vila | :) | 09:05 |
| mwhudson | vila: twisted already had a pretty anal parser and handled the single-range case | 09:07 |
| vila | 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 | 09:09 |
| === serg_ is now known as serg | ||
| bialix | hi guys! anybody home? | 09:57 |
| bialix | 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:00 |
| luks | I'd say management | 10:02 |
| bialix | hi luks | 10:02 |
| luks | hey | 10:02 |
| bialix | how are you? | 10:02 |
| luks | fine, thanks. you? | 10:02 |
| bialix | more or less | 10:02 |
| bialix | thanks for explanation | 10:03 |
| luks | well, that's just my opinion | 10:03 |
| bialix | my question raised because we have incorrect translation in Russian of this term | 10:03 |
| luks | and how I'd translate it to another language | 10:03 |
| bialix | I understand | 10:04 |
| bialix | translation in Russian is wrong because we have the word "control" here too, but it's false friend of translator | 10:05 |
| bialix | Russian control it's closer to "check" | 10:05 |
| luks | same here in slovak | 10:05 |
| bialix | :-) | 10:06 |
| bialix | I've started heavily using "daggy fixes" in my work | 10:07 |
| bialix | this very heavily influencing my style of work with VCS | 10:07 |
| luks | I don't think I could strictly follow that | 10:08 |
| luks | maybe for recent branches | 10:08 |
| luks | but definitely not for something old | 10:08 |
| bialix | well, in my case I need to maintain several branches in parallel, so it's work OK | 10:08 |
| bialix | and for old branches too | 10:08 |
| bialix | my mileage is different I suppose | 10:08 |
| luks | well, I'm a lazy person :) | 10:09 |
| bialix | me too, but daggy fixes make my life easier | 10:09 |
| bialix | because cherrypick in bzr sometimes painful | 10:09 |
| luks | the only feature I like in svn better | 10:10 |
| bialix | cherrypick? | 10:10 |
| luks | yep | 10:10 |
| bialix | IIUC this is inevitable downside of DAG-based systems | 10:13 |
| luks | exactly | 10:14 |
| jml | bialix: I'd say that the "control" part of VCS isn't terribly significant. | 10:15 |
| bialix | hi jml | 10:15 |
| bialix | jml: why not? | 10:15 |
| jml | bialix: "management" is close enough, I guess. | 10:15 |
| bialix | thanks | 10:16 |
| jml | bialix: but when I hear the phrase, I think "version $GENERIC_VERB $GENERIC_ABSTRACT_NOUN" | 10:16 |
| jml | version handler thing | 10:16 |
| bialix | :-) | 10:16 |
| bialix | ok, one more question: when you say "version" and "revision" -- what's difference? | 10:17 |
| bialix | VCS vs RCS | 10:17 |
| jml | not much. | 10:17 |
| jml | "version" has a connotation of "released version", I guess | 10:17 |
| bialix | version is more genric term? | 10:17 |
| jml | yeah. | 10:17 |
| jml | "revision" almost always refers to the result of a commit (in IT, anyway.) | 10:18 |
| bialix | I read "revision" as in "document revision" | 10:19 |
| jml | right, that's the broader sense | 10:19 |
| bialix | it's about editing the text, is not? | 10:19 |
| jml | a revision is what you get after you have revised something, usually a text. | 10:19 |
| bialix | i.e. when I fix some errors in the text? | 10:20 |
| jml | yeah. | 10:20 |
| bialix | or improve something? | 10:20 |
| bialix | thanks | 10:20 |
| bialix | the things much clearer now | 10:20 |
| bialix | it's so hard to translate VCS terms adequately | 10:21 |
| jml | I'll bet! | 10:21 |
| luks | doesn't russian have a commonly used equivalent? | 10:21 |
| bialix | that's the problem | 10:22 |
| bialix | we have some de0facto equivalent | 10:22 |
| bialix | de-facto | 10:22 |
| bialix | but sometimes they are represent svn-centric point of view | 10:22 |
| bialix | i.e. you have no pull/push in svn | 10:22 |
| davidstrauss | Revision is a bad term for VCS because it's colloquially used to mean a diff and the result of applying a diff. | 10:22 |
| luks | I think the the term applies to any vcs | 10:23 |
| bialix | davidstrauss: what will be better? | 10:23 |
| davidstrauss | bialix: commits should be called snapshots | 10:23 |
| luks | so if there were some manuals for csv or something, I'd use the term from there | 10:23 |
| luks | *cvs | 10:23 |
| davidstrauss | bialix: commits/revisions used to not be atomic, so you couldn't call them snapshots | 10:24 |
| bialix | luks: well, there is semi-official translation of svn | 10:24 |
| bialix | "svn book" | 10:24 |
| davidstrauss | bialix: but any modern vcs has atomic commits, so we ought to call them snapshots | 10:24 |
| luks | davidstrauss: but we don't :) | 10:24 |
| bialix | is not "commit" is the action | 10:24 |
| bialix | ? | 10:25 |
| bialix | but snapsot is the object | 10:25 |
| davidstrauss | bialix: See, that's another troublesome term | 10:25 |
| luks | depends, git uses it as the result of the action | 10:25 |
| davidstrauss | bialix: "Commit" can be the action of committing or the snapshot produced by committing | 10:25 |
| bialix | nice | 10:25 |
| davidstrauss | bialix: "Snapshot" is so unambiguous, I can even use it to define the confusing VCS terms. | 10:26 |
| bialix | I agree here | 10:27 |
| davidstrauss | bialix: It's a nice metaphor, too | 10:27 |
| luks | but it's not very translatable, I guess | 10:27 |
| davidstrauss | bialix: git could not call it a snapshot, though, because they have the staging area | 10:27 |
| luks | I can't think of a slovak translation for shapshot | 10:27 |
| bialix | for those who like photography? | 10:27 |
| davidstrauss | luks: What is the translation used for file system snapshotS? | 10:28 |
| bialix | for me snapshot is more about photo | 10:28 |
| luks | davidstrauss: I don't think there is one | 10:28 |
| davidstrauss | http://en.wikipedia.org/wiki/Snapshot_(computer_storage) | 10:28 |
| luks | we just use an expression to explain it | 10:28 |
| luks | can't think of a direct translation | 10:29 |
| davidstrauss | There are a few translations there in the inter-language links | 10:29 |
| luks | three words for russian :) | 10:30 |
| davidstrauss | It's pretty much impossible to find terms that work across languages. Computer terms are either metaphorical or made up | 10:30 |
| luks | so the same problem, I guess | 10:30 |
| luks | ah, no | 10:31 |
| davidstrauss | luks: I'm sure "commit | 10:31 |
| bialix | luks: in russian it's called "phot of file system" | 10:31 |
| davidstrauss | luks: I'm sure "commit" and "revision" are at least as bad | 10:31 |
| luks | davidstrauss: definitely | 10:31 |
| luks | I always laugh at the translation of commit in svn manuals | 10:31 |
| bialix | push is bad too | 10:31 |
| davidstrauss | luks: At least "snapshot" is unambiguous and tangible to English speakers | 10:31 |
| bialix | luks: in russian svn book "revision" called an "editing" | 10:32 |
| bialix | it's so crazy | 10:33 |
| bialix | davidstrauss: "git could not call it a snapshot, though, because they have the staging area" -- I disagree | 10:34 |
| bialix | their staging area is also "snapshotting" | 10:34 |
| davidstrauss | bialix: git isn't snapshotting anything | 10:34 |
| bialix | really? | 10:34 |
| davidstrauss | bialix: http://fourkitchens.com/blog/2009/02/03/importance-atomicity-or-why-git-staging-area-bad | 10:34 |
| bialix | looking into .git directory I see they're store actual state of the files | 10:35 |
| luks | davidstrauss: they are just applying a filter before they take the snapshot | 10:35 |
| davidstrauss | luks: no | 10:35 |
| luks | but I think it still is a shanpshot | 10:35 |
| davidstrauss | luks: nope | 10:35 |
| davidstrauss | 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:35 |
| davidstrauss | luks: Something can be in the git staging area but not in your working copy. | 10:36 |
| luks | hm, I didn't know that | 10:36 |
| davidstrauss | 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 |
| bialix | davidstrauss: roughly the same happens in interactive darcs commit | 10:37 |
| davidstrauss | luks: So, I think that violates the snapshot metaphor. | 10:37 |
| luks | davidstrauss: if you define it as a tree-level snapshot, yes | 10:37 |
| bialix | you mean the staging area is virtual, but real files are real? | 10:38 |
| davidstrauss | bialix: I mean a snapshot should be of your working tree | 10:38 |
| bialix | I understand | 10:38 |
| bialix | but... | 10:38 |
| luks | but the same thing applies to svn then | 10:38 |
| davidstrauss | bialix: A data structure that you stage changes into doesn't translate well to the snapshot metaphor | 10:38 |
| davidstrauss | luks: no | 10:38 |
| bialix | see! even in English you can use snapshot differently | 10:39 |
| davidstrauss | luks: svn allows selective commit, but the commit must be of files as they are in your working tree | 10:39 |
| luks | davidstrauss: they might be out of date | 10:39 |
| luks | davidstrauss: svn will automatically merge, if possible | 10:39 |
| davidstrauss | luks: svn requires you to update prior to commit if you're committing to changed files | 10:39 |
| luks | you can commit a revision that doesn't represent your working tree | 10:39 |
| luks | sure, but it doesn't have to be the modified files | 10:40 |
| luks | source code files usually depend on each other | 10:40 |
| davidstrauss | 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:40 |
| davidstrauss | luks: svn takes snapshots from the directory you're in and below. | 10:42 |
| davidstrauss | anyway, it's way past my bedtime | 10:42 |
| davidstrauss | luks: I rag plenty on svn/git in that blog post, anyway | 10:42 |
| davidstrauss | luks: And I do bring up that very issue | 10:43 |
| Jemsquash | 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:19 |
| lifeless | 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 |
| lifeless | Jemsquash: if they aren't erroring, perhaps you are invoking 'bzr add' in a strange way? | 12:27 |
| Jemsquash | I am just typing bzr add. | 12:28 |
| lifeless | what does it report? | 12:28 |
| Jemsquash | I have 3 revisions in the branch so it is definitely initialised. | 12:28 |
| Jemsquash | nothing. | 12:28 |
| Jemsquash | 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:29 |
| Jemsquash | I initially did an add and it seemed to add a bunch of files, but seemed to leave a whole lot out. | 12:30 |
| lifeless | would it be possible to pastebin? | 12:30 |
| lifeless | bzr st | 12:30 |
| lifeless | bzr add | 12:30 |
| lifeless | bzr st | 12:30 |
| lifeless | oh, actually | 12:30 |
| lifeless | I think I know | 12:30 |
| lifeless | if the things that are not getting added are all bzr trees themselves, that is why | 12:30 |
| lifeless | what does 'bzr info <somethingthatisn'tgettingadded>' report? | 12:30 |
| Jemsquash | 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 |
| lifeless | 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 |
| Jemsquash | I'm a bit lost when you say that things not being added are all bzr trees themselves. | 12:31 |
| Jemsquash | Ok - perhaps. | 12:32 |
| Jemsquash | I'll have an investigation into looking for .svn folders or .cvs folders. It is a possibility although I will be surprised. | 12:32 |
| lifeless | to demo now | 12:32 |
| lifeless | cd /tmp | 12:32 |
| lifeless | bzr init foo | 12:32 |
| lifeless | cd foo | 12:32 |
| lifeless | bzr init bar | 12:33 |
| lifeless | bzr add | 12:33 |
| lifeless | bzr st | 12:33 |
| lifeless | you should see that bar hasn't been added | 12:33 |
| Jemsquash | yep. That sort of makes sense. | 12:33 |
| Jemsquash | Is that due to the shared repo containing branches etc? | 12:33 |
| lifeless | no, its because we haven't finished the nested trees support | 12:34 |
| Jemsquash | ah ok | 12:34 |
| lifeless | if it were to add bar, it would be versioning a link to bar, like a svn external | 12:34 |
| Jemsquash | I'm not sure I want to understand this concept of nested trees. | 12:35 |
| lifeless | heh | 12:35 |
| Jemsquash | it sounds scary :) | 12:36 |
| lifeless | its pretty straight forward; you have a bzr tree for a library or something that you want to embed in a larger tree | 12:36 |
| Jemsquash | so the tree in effect is a project with subprojects in a way. | 12:37 |
| lifeless | yes | 12:38 |
| Jemsquash | 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:38 |
| Jemsquash | I'm confusing myself with recursion when I reread my own post. | 12:39 |
| Jemsquash | 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:41 |
| Jemsquash | If I commit a change to the nested tree will it change the revno of the containing branch? | 12:42 |
| bialix | anybody knows approx timeframe for 1.15 release? | 12:43 |
| lifeless | 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 |
| lifeless | if it was a new project, you've have to be doing merges, and it would be less conveninet | 12:45 |
| lifeless | bialix: sorry, not offhand | 12:45 |
| bialix | well, when UDS then? | 12:45 |
| Jemsquash | 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:49 |
| Jemsquash | Thanks for your suggestion on checking to see if the unadded files & directories are themselves under revision control. | 12:53 |
| bialix | UDS will be 25-29 May. So I suppose 1.15 will be before or after. right? | 12:56 |
| lifeless | bialix: I'm not exactly sure; I'd ask the list if you need to know | 12:57 |
| bialix | ok | 12:57 |
| phanatic | hi, i need to upgrade my branch to "rich-root-pack" to use split, right? | 13:58 |
| jelmer_ | phanatic: yes | 14:05 |
| jelmer_ | mwhudson: yes | 14:05 |
| phanatic | jelmer_: thanks. bzr upgrade --rich-root-packs should do the trick, right? | 14:07 |
| jelmer_ | phanatic: if you're restricted to bzr <= 1.0, yes | 14:09 |
| jelmer_ | phanatic: (1.9-rich-roots also exists, for example) | 14:09 |
| phanatic | jelmer_: any ideas why i get this: http://pastebin.com/d37856392 ? | 14:10 |
| jelmer_ | phanatic: you must upgrade the repo, not the branch | 14:10 |
| phanatic | ah, thanks :) | 14:11 |
| Jemsquash | 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? | 14:46 |
| === vxnick_ is now known as vxnick | ||
| === dereine[OFF] is now known as dereine | ||
| NfNitLoop | Jemsquash: I don't know about clearcase->svn, but svn->bzr is pretty easy. | 16:22 |
| NfNitLoop | The only thing I can think of is that you might lose some metadata in the clearcase->svn migration. | 16:23 |
| NfNitLoop | SVN doesn't do non-linear history. | 16:23 |
| limor | hi | 18:00 |
| limor | I have a question? any german people? | 18:02 |
| limor | the informations of an branch like history.. are they stored in the branch or in the repository folder? | 18:23 |
| Peng_ | limor: The history is stored in the repository. | 18:30 |
| Peng_ | 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:31 |
| limor | 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:37 |
| mrooney | I'm attempting to use loggerhead to view a remote svn branch, does anyone know if this should work? | 18:51 |
| === KnightWhoSaysNi is now known as BlackKnight | ||
| mrooney | I am trying for example ./serve_branches svn+http://svnserver/repos/trunk | 18:51 |
| Peng_ | mrooney: That's an interesting idea. | 18:53 |
| james_w | mrooney: does serve-branches load plugins? | 18:53 |
| Peng_ | james_w: Yeah. | 18:53 |
| Peng_ | It tells me "... is not a directory" though. | 18:53 |
| mrooney | do I need some switch to tell loggerhead it is a remote branch? maybe it has nothing to do with bzr-svn? | 18:54 |
| === beuno_ is now known as beuno | ||
| Peng_ | From the file/class names, it seems filesystem-centric. | 18:57 |
| james_w | mrooney: serve-branches serves all branches under a directory, so that's probably not going to work | 18:57 |
| mrooney | oh darn and the repository doesn't work either | 18:58 |
| mrooney | 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 |
| mrooney | although I bet it would be useful to others as well if it could work the aforementioned way | 18:59 |
| james_w | yep | 18:59 |
| james_w | loggerhead can do it fine | 18:59 |
| james_w | just serve-branches can't set it up in the right way it seems | 19:00 |
| james_w | is the other launch script still there? | 19:00 |
| james_w | start-loggerhead I think it was | 19:00 |
| james_w | or does serve-branches say anything about a config file in the source? | 19:00 |
| NEBAP | hi guys | 19:00 |
| beuno | no config file for serve-branches (yet) | 19:00 |
| mrooney | oh okay it works fine on my import | 19:01 |
| mrooney | but it doesn't have the fancy ajax expanding of changes or the unified diff / side by side toggle | 19:01 |
| mrooney | does LP have its own version or do I need trunk? | 19:01 |
| beuno | mrooney, trunk has those | 19:01 |
| mrooney | ah ok let me grab that | 19:01 |
| beuno | LP uses trunk | 19:01 |
| mrooney | fancy :) | 19:01 |
| beuno | we like cutting edges :) | 19:02 |
| vxnick_ | could I ask for your (collective) advise on something? | 19:03 |
| NEBAP | 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 |
| mrooney | hmm it looks the same to me | 19:03 |
| mrooney | I will take a look later | 19:03 |
| jelmer_ | mrooney: I think I know | 19:04 |
| jelmer_ | mrooney: loggerhead tries to store a cache in the branch | 19:04 |
| jelmer_ | mrooney: and that might rely on local file access | 19:04 |
| jelmer_ | beuno: ^ | 19:04 |
| beuno | jelmer_, it does | 19:05 |
| beuno | well | 19:05 |
| beuno | not *in* the branch | 19:05 |
| beuno | in a /tmp dir | 19:05 |
| jelmer_ | beuno: oh, ok | 19:05 |
| beuno | although, tbh, I don't know what it would do with remote branches | 19:05 |
| jelmer_ | beuno: so that doesn't explain why ./serve-branches <svn-url> doesn't work | 19:05 |
| beuno | lifeless and I tried it on SVN branches locally, and it owrked | 19:06 |
| beuno | jelmer_, right. Other than "I have never tried that" :) | 19:06 |
| beuno | it theory, it *should* work | 19:06 |
| vxnick_ | 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:06 |
| jelmer_ | beuno: serve-branches:47 has a check that the specified path is a directory :-) | 19:07 |
| beuno | jelmer_, ah. There you go | 19:07 |
| beuno | because we do directory navigation | 19:07 |
| beuno | as well as branches | 19:07 |
| beuno | I guess we need a different path when it's already a branch | 19:08 |
| jelmer_ | beuno: directory navigation could be done using Transport though | 19:08 |
| jelmer_ | beuno: Transport.list_dir works on svn transports | 19:08 |
| beuno | jelmer_, interesting. May work better. | 19:08 |
| beuno | I guess that would be a bug | 19:08 |
| beuno | vxnick_, you could use push-and-update | 19:09 |
| beuno | and block .bzr dir from being served | 19:09 |
| vxnick_ | beuno: thanks - does that push to the central server and then update the remote production server? | 19:09 |
| beuno | vxnick_, pushes and updates the working tree in the remote location | 19:09 |
| beuno | you need ssh | 19:09 |
| vxnick_ | thanks, I'll take a look at its docs | 19:10 |
| beuno | welcome' | 19:10 |
| Peng_ | Would using transports hurt Loggerhead's performance on local branches? | 19:10 |
| jelmer_ | Peng_: it would have a very slight overhead | 19:11 |
| Peng_ | BTW, Loggerhead does support remote branch references. | 19:12 |
| jelmer_ | Peng_: not a noticable impact | 19:12 |
| Peng_ | You can't pass a remote location to serve-branches, but if you have a branch reference locally, it works. | 19:13 |
| Peng_ | Bit slow, though. | 19:13 |
| Peng_ | beuno: It seems to build the caches correctly on remote branches. | 19:19 |
| jelmer_ | bug 371787 | 19:20 |
| ubottu | Launchpad bug 371787 in loggerhead "should use transports rather than local file access" [Undecided,New] https://launchpad.net/bugs/371787 | 19:20 |
| Peng_ | beuno: (Well, references, but that still loads the remtoe branch.) | 19:20 |
| beuno | ah | 19:20 |
| beuno | thanks herb | 19:20 |
| beuno | er | 19:20 |
| beuno | and jelmer_ | 19:20 |
| === AnMaster_ is now known as AnMaster | ||
| === BasicPRO is now known as BasicOSX | ||
| mdz | I have a bzr repository which seems to fail to convert using bzr upgrade --1.9-rich-root | 19:36 |
| mdz | it runs for a very long time and never terminates | 19:36 |
| === beuno_ is now known as beuno | ||
| jelmer_ | beuno, peng_: hmm, that was actually pretty easy | 19:50 |
| beuno | mdz, is .bzr.log helpful at all? | 19:50 |
| mdz | 66.413 Using fetch logic to copy between KnitPackRepository('file:///home/mdz/s | 19:51 |
| mdz | rc/.bzr/repository.backup/')(<RepositoryFormatKnitPack1>) and KnitPackRepository | 19:51 |
| mdz | ('file:///home/mdz/src/.bzr/repository/')(<RepositoryFormatKnitPack6RichRoot>) | 19:51 |
| mdz | 66.413 fetch up to rev {None} | 19:51 |
| mdz | 2654.157 Traceback (most recent call last): | 19:51 |
| mdz | [traceback from where I interrupted it] | 19:51 |
| mdz | so that's about 45 minutes with no indication of progress for most of it | 19:51 |
| beuno | mdz, if it's a big repo, I think it could actually take ages as it recompresses all it's deltas, etc | 19:51 |
| beuno | but it should be eating CPU like crazy | 19:52 |
| mdz | beuno: it did eat CPU, but the progress indicator didn't update | 19:52 |
| beuno | mdz, that's "normal" | 19:52 |
| beuno | how big is the repo? | 19:52 |
| beuno | I've heard big repos take up 18 hours in this kind of jump :) | 19:52 |
| mdz | the repo is about 1.2G | 19:53 |
| Peng_ | jelmer_: What was? | 19:53 |
| beuno | mdz, sounds normal then. Probably one of those things to do before you go to bed :) | 19:53 |
| mdz | beuno: I will give it another try. if it doesn't complete by this time tomorrow, I will renew my suspicions | 19:55 |
| jelmer_ | Peng_: switching to transports | 19:56 |
| beuno | mdz, you should also be aware that all remote branches will need to be rich-root as well | 19:56 |
| beuno | or you won't be able to interact with them | 19:56 |
| mdz | beuno: that's what has actually triggered the upgrade for me; one of the branches I work with has converted and I could no longer branch from it | 19:57 |
| Peng_ | jelmer_: Wait, did you actually do it, or just see how? | 19:58 |
| mdz | beuno: does this mean it's impossible to share a repository between branches unless they're all upgraded? | 19:58 |
| beuno | mdz, yes. It sucks. | 19:58 |
| mdz | beuno: or will upgrading the repository fetch massive amounts of data from remote branches? | 19:58 |
| mdz | hmm | 19:58 |
| beuno | mdz, they won't work if they aren't rich-root on the other end | 19:58 |
| beuno | but | 19:58 |
| mdz | sounds like I should quit using a repository | 19:58 |
| beuno | there's light at the end of the tunnel | 19:58 |
| beuno | 2.0 format will be rich-root | 19:59 |
| mdz | rather than spending days converting it | 19:59 |
| beuno | and there won't be any non-rich-root anymore | 19:59 |
| beuno | mdz, yeah, I keep them in shared repos between projects | 19:59 |
| vxnick_ | is there anything like push-and-update but for commits? | 20:00 |
| beuno | vxnick_, well, checkouts accomplish that to some extent | 20:00 |
| beuno | but I don't know if push-and-update plugin works with it | 20:00 |
| vxnick_ | beuno: I just want to avoid having to login to the production machine to update | 20:00 |
| jelmer_ | Peng_: I actually fixed it | 20:01 |
| vxnick_ | I want to do: local dev --> commit to central repo --> update remote production machine | 20:01 |
| Peng_ | jelmer_: Oh, cool. :) | 20:01 |
| mdz | beuno: I just use one big repo for checking out everything | 20:01 |
| beuno | vxnick_, ah, two separate machines | 20:01 |
| vxnick_ | beuno: yup :) | 20:01 |
| beuno | mdz, yes, I used to do that. Had to move to per-project :) | 20:01 |
| beuno | mdz, after 2.0, the madness should stop, and we can all finally be happy | 20:02 |
| beuno | vxnick_, I don't think there's anything in bzr that will let you do that | 20:02 |
| vxnick_ | beuno: hmm. I think you're right but thought I'd ask | 20:02 |
| beuno | vxnick_, you can put together a plugin if you're good with python | 20:02 |
| beuno | vxnick_, or a cronjob :) | 20:02 |
| vxnick_ | beuno: I'm a complete noob :) | 20:02 |
| vxnick_ | beuno: a cron is an option but it'd be nice to have it automated | 20:03 |
| mdz | beuno: if I just blow away my repo, will that break all of my local branches, or will they continue to work? | 20:03 |
| vxnick_ | beuno: on second thoughts, it's probably best to manually run bzr update just in case there are any conflicts | 20:03 |
| beuno | mdz, break completely and loose all your data | 20:04 |
| mdz | beuno: sweet! | 20:04 |
| beuno | mdz, I'd recommend you branch from the repo for big branches so it's local and fast | 20:04 |
| mdz | so I guess I 1) make sure all my changes are pushed to LP, 2) blow away my repo, 3) re-download all my branches | 20:04 |
| beuno | and then bring in the rest remotely on a need-to-use basis | 20:05 |
| beuno | mdz, you can branch them locally instead, outside of the shared repo | 20:05 |
| mdz | beuno: oh, good idea | 20:05 |
| beuno | mdz, but then again, you're so close to the tubes, not sure it would make a dramatic difference | 20:06 |
| mdz | beuno: I'm at home, narrower tubes | 20:06 |
| beuno | right, avoid plumbing all together then | 20:06 |
| vxnick_ | do you know of any bzr plugins to allow shell-type files to be run? | 20:08 |
| jelmer_ | beuno, Peng_: how do I run the loggerhead testsuite? | 20:08 |
| beuno | jelmer_, nosetests | 20:08 |
| beuno | vxnick_, shell hooks. let me find some documentation for you.. | 20:08 |
| jelmer_ | beuno: is there some way to enter a debugger in case of tracebacks, like BZR_PDB=1 ? | 20:09 |
| vxnick_ | beuno: thank you kindly :) | 20:09 |
| beuno | jelmer_, I... don't know :) | 20:09 |
| jelmer_ | beuno: thanks | 20:09 |
| vxnick_ | beuno: I'm thinking that perhaps bzr upload would work if I called it from a shell script on the post_commit hook | 20:09 |
| vxnick_ | from central server --> deployment server | 20:10 |
| mrooney | beuno: I checked out lp:loggerhead/trunk now and am running that, but I still don't see any of the new stuff LP has, do I need to do anything special? | 20:10 |
| === vxnick_ is now known as vxnick | ||
| beuno | mrooney, nope, you sould see all of it | 20:11 |
| * Peng_ has never run Loggerhead's test suite. Coughcough. | 20:11 | |
| mrooney | beuno: hmph, I'm stuck then | 20:12 |
| beuno | vxnick, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-hooks | 20:14 |
| beuno | http://bazaar-vcs.org/BzrHooks | 20:15 |
| vxnick | beuno: cheers! | 20:15 |
| beuno | mrooney, did you install loggerhead from a package? | 20:15 |
| mrooney | beuno: no I checkout out lp:loggerhead/trunk and ran serve_branches | 20:15 |
| beuno | mrooney, do you didn't have it installed previously? | 20:16 |
| mrooney | beuno: well I had run 1.10 in the same way previously | 20:16 |
| beuno | mrooney, can you try getting lp:loggerhead instead? | 20:16 |
| mrooney | yeah that is what I originally used | 20:16 |
| mrooney | then I tried trunk and it looked the same | 20:16 |
| beuno | well, it's all there is :) | 20:17 |
| mrooney | beuno: what is all there is? | 20:17 |
| beuno | mrooney, you don't have serve-branches in /usr/bin? | 20:17 |
| beuno | mrooney, lp:loggerhead | 20:17 |
| mrooney | beuno: nope I don't have it except in the 1.10 and trunk checkout | 20:18 |
| === dereine is now known as dereine[OFF] | ||
| === dereine[OFF] is now known as dereine | ||
| beuno | mrooney, so | 20:26 |
| beuno | you're doing: bzr branch lp:loggerhead; cd loggerhead; ./serve-branches | 20:26 |
| mrooney | beuno: well, bzr co lp:loggerhead/trunk loggerhead-trunk; cd loggerhead-trunk; ./server-branches path | 20:27 |
| mrooney | well except for that typo in the last command | 20:28 |
| mrooney | is anyone able to attempt to reproduce it? as long as you have a local repository it should take about a minute | 20:30 |
| beuno | and when you hit localhost:8080 | 20:30 |
| beuno | you get the old version? | 20:30 |
| mrooney | beuno: well I assume, I don't have the ajax expansions or side by side vs unified diff options | 20:32 |
| mrooney | if I kill the trunk process it stops working so I am fairly sure it is being served from the process I think it is | 20:32 |
| Peng_ | Could it be importing the wrong "loggerhead" somehow? Does that even work anymore? I broke it for UserBranches, but I'm not sure about regular Branches. | 20:34 |
| mrooney | I would say it could have something to do with me first using the 1.10, but in retrospect I see lp:loggerhead goes to trunk anyway | 20:35 |
| mrooney | so I never actually had 1.10 | 20:35 |
| mrooney | Peng_: do you have a repos to test with? | 20:36 |
| Peng_ | mrooney: Test what? | 20:37 |
| mrooney | to see if someone else serving from trunk gets what I expect, the LP interface | 20:37 |
| mrooney | maybe they don't! | 20:37 |
| jelmer_ | beuno, Peng_: loggerhead works on svn and git branches now :-) | 20:56 |
| beuno | jelmer_, you're unstoppable | 20:57 |
| beuno | have you files a merge proposal for the tweaks? | 20:57 |
| mrooney | jelmer_: so I can grab your branch and use a remote svn branch? | 20:57 |
| BasicOSX | just a /poke for input regarding 1.15rc1. My initial post had 1 follow-up and I've responded to that. Looking for general feel on the state of the code and bug fixes so a 1.15rc1 can be created. | 20:57 |
| jelmer_ | mrooney: yeah, the last two branches I submitted for merging into loggerhead | 20:59 |
| jelmer_ | mrooney: as well as the latest bzr-svn and subvertpy | 20:59 |
| jelmer_ | beuno: and mercurial :-) | 20:59 |
| mrooney | ah okay I'll merge those locally | 20:59 |
| beuno | jelmer_, really? bzr works with hg? | 20:59 |
| jelmer_ | beuno: well enough for the history | 21:00 |
| jelmer_ | beuno: I haven't tried looking at the diffs yet | 21:00 |
| beuno | amazing | 21:00 |
| jelmer_ | mrooney: there's one caveat, you'll have to disable the caching in bzr-svn because loggerhead uses threads | 21:00 |
| beuno | jelmer_, if you point me at the MP, I'll review/merge | 21:00 |
| beuno | ah | 21:00 |
| beuno | Peng_ got to it :) | 21:01 |
| beuno | he can merge | 21:01 |
| Peng_ | beuno: OK. | 21:01 |
| jelmer_ | beuno: https://code.edge.launchpad.net/~jelmer/loggerhead/transport/+merge/6179, https://code.edge.launchpad.net/~jelmer/loggerhead/transport/+merge/6179 | 21:01 |
| jelmer_ | I mean https://code.edge.launchpad.net/~jelmer/loggerhead/fix-nick/+merge/6180 | 21:02 |
| Peng_ | Huh, I haven't seen any code review emails. I'm still getting other LP mail... | 21:02 |
| LarstiQ | jelmer_: dude! asom! | 21:03 |
| Peng_ | BTW: I don't want to review fix-nick, since I'm not qualified to comment on branch._get_nick. | 21:04 |
| Peng_ | Ahh, here the emails are; they're just a bit late. | 21:05 |
| beuno | jelmer_, I had to change the nick bit so it didn't try and grab it remotely for checkouts | 21:06 |
| beuno | I think this will revert back to that behaviour? | 21:06 |
| beuno | or does the local=true prevent it? | 21:06 |
| jelmer_ | beuno: local=True prevents it | 21:08 |
| beuno | jelmer_, thanks. Will merge it | 21:09 |
| Peng_ | I could fix my review comments on transport and merge it. OK? | 21:09 |
| beuno | Peng_, go for it! | 21:10 |
| Peng_ | OK. | 21:10 |
| jelmer_ | Peng_: thanks! | 21:12 |
| mwhudson | jelmer_: what was i asking? :) | 21:21 |
| jelmer_ | mwhudson: :-) | 21:21 |
| jelmer_ | mwhudson: Where I would be at UDS | 21:21 |
| jelmer_ | s/Where/Whether/ | 21:21 |
| mwhudson | jelmer_: oh right | 21:21 |
| mwhudson | jelmer_: good! | 21:21 |
| jelmer_ | mwhudson: more bzr-git issues to work on ? | 21:22 |
| beuno | jelmer_, you're going? | 21:22 |
| jelmer_ | beuno: yep | 21:22 |
| beuno | yay | 21:22 |
| * beuno will be there | 21:22 | |
| mwhudson | jelmer_: i can't quite remember why i was asking now :) | 21:22 |
| jelmer_ | beuno: Cool :-) | 21:22 |
| beuno | Peng_, how about you? | 21:23 |
| mwhudson | jelmer_: testing git imports got stalled by having our staging code import machine stolen by IS | 21:23 |
| jelmer_ | IS? | 21:23 |
| jelmer_ | mwhudson: oh btw, I fixed another excessive memory usage issue in dulwich | 21:24 |
| mwhudson | information services | 21:24 |
| mwhudson | jelmer_: can i cope with the kernel yet? :) | 21:25 |
| beuno | aka, sysadmins | 21:25 |
| jelmer_ | mwhudson: maybe | 21:25 |
| jelmer_ | mwhudson: samba works pretty well now | 21:25 |
| mwhudson | jelmer_: cool | 21:25 |
| jelmer_ | it's still a bit slow though, takes a couple of hours | 21:25 |
| mwhudson | jelmer_: importing into what? --1.9-rich-root | 21:26 |
| mwhudson | jelmer_: hours!?! we have had cscvs imports take _days_ | 21:26 |
| jelmer_ | mwhudson: development6 | 21:26 |
| mwhudson | o | 21:26 |
| mwhudson | k | 21:27 |
| jelmer_ | mwhudson: the fact that creating an inventory in 1.9-rich-root is O(tree) makes it really slow | 21:27 |
| LarstiQ | slower than several hours you mean? | 21:28 |
| jelmer_ | LarstiQ: yeah | 21:28 |
| jelmer_ | you spent most of the time serializing and deserializing inventories | 21:28 |
| mwhudson | jelmer_: i can believe that | 21:28 |
| jelmer_ | s/spent/spend/ | 21:28 |
| Peng_ | beuno: Me what? | 21:30 |
| beuno | Peng_, are you going to UDS? | 21:30 |
| Peng_ | beuno: No. | 21:30 |
| Peng_ | beuno & jelmer_: I merged the transport branch. | 21:30 |
| jelmer_ | Peng_: Cool, thanks! | 21:30 |
| beuno | Peng_, you couldn't come? or didn't get an offer to be sponsored? | 21:31 |
| jelmer_ | mwhudson: what's the best way to get those OOo / samba branches updating again | 21:31 |
| jelmer_ | mwhudson: ? | 21:31 |
| mwhudson | jelmer_: again? | 21:31 |
| Peng_ | beuno: Um, let's say both. I don't even know anything about UDS. | 21:31 |
| jelmer_ | mwhudson: Well, last time you asked tbm (?) to trigger an update | 21:32 |
| jelmer_ | mwhudson: but doing it that way seems a bit labor-intensive :-) | 21:32 |
| beuno | Peng_, we should get you to one of them and hack :) | 21:34 |
| mwhudson | jelmer_: spm | 21:36 |
| mwhudson | jelmer_: they've got stuck again? | 21:36 |
| Peng_ | beuno: I dunno. I'm shy. And I dunno how useful I'd be. I still haven't done any major work. Plus I should've started eating dinner 20 minutes ago, and I'll go do that now. See you later, everyone. :) (Which is convenient for getting out of this conversation, but also true.) | 21:36 |
| beuno | Peng_, enjoy :) | 21:37 |
| jelmer_ | mwhudson: yeah | 21:39 |
| Peng_ | Quick question: does transport.stat() follow symlinks? | 21:39 |
| jelmer_ | mwhudson: but seem stuck even for smaller stuff, so it's impossible to use launchpad with reasonably large (>= 10k or something) development6 branches | 21:39 |
| mwhudson | jelmer_: two points i guess: 1) we should be able to make changes soon that allow us to up the timeout | 21:42 |
| mwhudson | 2) this means 15 minutes with no activity report -- that much be a bug somewhere | 21:42 |
| mwhudson | must | 21:42 |
| jelmer_ | mwhudson: when does that timeout happen, during pull ? | 21:43 |
| mwhudson | jelmer_: yes | 21:43 |
| vxnick | what's the best way to move my repository including the ignored list? | 21:44 |
| mwhudson | jelmer_: also branch outside a shared repo is really slow for dev6, i guess this is an indication of the same problem | 21:44 |
| mwhudson | jelmer_: have you been having problems with mirrored branches too, or just hosted? | 21:44 |
| jelmer_ | mwhudson: both | 21:45 |
| mwhudson | :( | 21:45 |
| LarstiQ | jelmer_: tbm is Martin Michlmayer :) | 21:47 |
| LarstiQ | vxnick: do you mean branch? Repositories don't have ignore lists. | 21:47 |
| vxnick | LarstiQ: sorry, that's correct | 21:47 |
| LarstiQ | vxnick: assuming the ignore list is nicely committed and everything, `bzr push` would be the operation of choice. | 21:48 |
| vxnick | LarstiQ: push doesn't move the files though does it, just the history? | 21:48 |
| jelmer_ | LarstiQ: ahh | 21:48 |
| jelmer_ | LarstiQ: Too many TLA's >-) | 21:48 |
| LarstiQ | jelmer_: there is only one tbm! ;) | 21:49 |
| LarstiQ | vxnick: the history is the important bit :) | 21:49 |
| LarstiQ | vxnick: a working tree can always be constructed if you have the history | 21:49 |
| LarstiQ | vxnick: where do you want to move it from, and whereto? | 21:49 |
| vxnick | LarstiQ: how so? I'm looking to shift the entire branch from my local machine to a remote server | 21:49 |
| LarstiQ | vxnick: does it even need a working tree then? Usually the answer is no. | 21:50 |
| vxnick | LarstiQ: but ideally I want to move the entire shared-repo | 21:50 |
| vxnick | LarstiQ: it does in this case as I want to have the files viewable through a system similar to trac | 21:51 |
| LarstiQ | vxnick: then you do not need a working tree. | 21:51 |
| LarstiQ | vxnick: the system like trac will provide it. | 21:51 |
| LarstiQ | vxnick: like, Loggerhead mwhudson, Peng_ and jelmer have been talking about. | 21:51 |
| vxnick | LarstiQ: thanks I'll have a read :) | 21:52 |
| LarstiQ | vxnick: for pushing an entire repo there is a repo-push plugin iirc (http://bazaar-vcs.org/BzrPlugins) | 21:52 |
| vxnick | LarstiQ: that looks ideal, many thanks! | 21:52 |
| LarstiQ | vxnick: np, let me know how it went | 21:53 |
| vxnick | will do | 21:53 |
| fullermd | q | 21:54 |
| * fullermd slaps his mouse. | 21:54 | |
| vxnick | LarstiQ: worked a treat, thanks again :) | 21:59 |
| LarstiQ | vxnick: good :) | 22:00 |
| jfroy | jelmer: I just read a message you wrong on the mailing list where you mention push_merged_revisions. I'm not familiar with that setting, is it new? | 22:08 |
| jfroy | *you wrote | 22:08 |
| jelmer_ | jfroy: no, it's been there for a while but never has been announced very publicly | 22:13 |
| jfroy | Am I guessing correctly that it pushes RHS revisions as separate svn commits when pushing a merge revision? | 22:13 |
| jfroy | *as separate svn revisions | 22:14 |
| jelmer_ | jfroy: yes, onto a separate branch | 22:16 |
| jelmer_ | or rather, separate branches | 22:17 |
| jfroy | I'm not sure I | 22:17 |
| jfroy | *I'm following completely. | 22:17 |
| jfroy | Are you saying it creates a new "branch" in svn? | 22:17 |
| jelmer_ | jfroy: yes | 22:17 |
| jelmer_ | and uses the bzr branch nick for the branch name in svn | 22:17 |
| jfroy | And I assume it guesses the bath based on its guess of the repository layout? | 22:18 |
| jelmer_ | so if you did a commit in a bzr branch called "feature-a" and then merged it into trunk | 22:18 |
| jfroy | *the path | 22:18 |
| jelmer_ | bzr-svn would push the commits in feature-a into branches/feature-a in subversion | 22:18 |
| jelmer_ | and the merge commit onto trunk | 22:18 |
| jfroy | gotcha | 22:18 |
| jfroy | what happens if you pushed feature-a to svn yourself | 22:18 |
| jfroy | then merge feature-a into trunk (locally) and push trunk | 22:18 |
| jfroy | I assume, like any other bzr-svn push, that it will read the bzr-svn revprop and do the right thing? | 22:19 |
| jelmer_ | jfroy: yes | 22:19 |
| jfroy | e.g. it will see it has no revisions to push, then move on to the merge revision in trunk | 22:19 |
| jfroy | I like it :) | 22:19 |
| jfroy | So where do I sign up for this goodness. | 22:20 |
| jfroy | bazaar.conf? | 22:20 |
| jelmer_ | jfroy: yeah | 22:21 |
| jelmer_ | or locations.conf / subversion.conf for individual repo's | 22:21 |
| jfroy | right, it's defined on BranchConfig which inherits from Config | 22:21 |
| jfroy | so it should pick up the usual behaviors of bzr's config machinery | 22:22 |
| jfroy | I think you should advertise it more. | 22:24 |
| jfroy | It's pretty nifty :p | 22:25 |
| jelmer_ | I haven't used it much myself so it may still have some rough edges | 22:27 |
| jelmer_ | I agree it's pretty nifty though :-) | 22:27 |
| jfroy | mmm | 22:28 |
| jfroy | Well if I hit any snags I'll file bugs, as usual. | 22:28 |
| jelmer_ | thanks | 22:32 |
| === thekorn__ is now known as thekorn | ||
| flacoste | hi there | 22:51 |
| flacoste | i want to open a branch and look at the commit messages from a specific revision onward | 22:51 |
| flacoste | any pointers on how to use bzrlib to achieve this? | 22:52 |
| flacoste | i'm looking at log.py (but my head spins) | 22:52 |
| lifeless | moin | 22:52 |
| thumper | hmm... | 22:53 |
| mwhudson | log.py is pretty much brain-pain | 22:53 |
| thumper | merge sorted ? | 22:53 |
| flacoste | thumper: i don't know what this means | 22:53 |
| mwhudson | flacoste: all revisions, or just mainline? | 22:53 |
| thumper | flacoste: it wasn't for you :) | 22:53 |
| flacoste | just mainline | 22:53 |
| flacoste | lol | 22:53 |
| thumper | just mainline is easy | 22:53 |
| lifeless | flacoste: b = bzrlib.branch.Branch.open(url) | 22:53 |
| flacoste | yeah, i assumed so | 22:53 |
| lifeless | b.lock_read() | 22:53 |
| lifeless | revid = b.revno2revid(revno) | 22:54 |
| lifeless | for revid in b.iter_revision_history(revid): | 22:54 |
| lifeless | print b.repository.revision(revid).message | 22:54 |
| lifeless | or ~ that anyhow | 22:55 |
| lifeless | iter_revisions or whatever its called is faster than getting inidividual revisions | 22:55 |
| flacoste | ok and this will return revision from revno and more recent? | 22:55 |
| flacoste | actually, excluding revno | 22:55 |
| flacoste | i assume | 22:55 |
| lifeless | oh, you want more recent | 22:56 |
| lifeless | iter_revision_history(b.last_revision) | 22:56 |
| lifeless | and then test for the exit point | 22:56 |
| flacoste | makes sense | 22:56 |
| flacoste | thanks a lot! | 22:56 |
| flacoste | how do i release the lock? | 22:57 |
| mwhudson | b.unlock() | 22:57 |
| === thekorn__ is now known as thekorn | ||
| ronny | LarstiQ: sup on the easy_install issues? | 23:02 |
| igc | morning | 23:02 |
| jelmer_ | hi ian | 23:04 |
| flacoste | the only iter_ i find on branch is iter_merge_sorted_revisions | 23:06 |
| igc | hi jelmer_ | 23:11 |
| thumper | igc: composite trees? | 23:12 |
| === dereine is now known as dereine[OFF] | ||
| igc | thumper: back to reviewing them today | 23:12 |
| thumper | igc: cool | 23:12 |
| igc | thumper: sorry for the delay - just not well enough last week | 23:12 |
| thumper | ok | 23:12 |
| abentley | igc: IIRC, the big sticking point is the text filtering. | 23:15 |
| igc | abentley: hi. Right | 23:15 |
| igc | abentley: a parameter exists in the WT API but not the Tree one | 23:16 |
| abentley | igc: CompositeTree can contain RevisionTrees and WorkingTrees, but only the WorkingTree version supports text filtering. | 23:16 |
| abentley | igc: Why isn't that already causing problems? | 23:16 |
| igc | abentley: I'll think hard about it today. What problems would you expect? | 23:17 |
| abentley | igc: I would expect bzr cat -r -1 to raise an exception because an unknown parameter was passed into it. | 23:17 |
| abentley | igc: Where is text filtering actually used? | 23:18 |
| poolie | igc, i like your three/four wishes, but they're a bit big to be used there | 23:18 |
| poolie | by which i mean, i suppose, that "adoption blockers banished" could be just the only item on the roadmap for the whole duration of the project :) | 23:19 |
| poolie | but i suppose it's fine | 23:19 |
| igc | abentley: it's used implicitly most of the time | 23:20 |
| igc | abentley: and explicitly in some cases like cat and export | 23:20 |
| abentley | igc: So it defaults to True. That's pretty gutsy. | 23:22 |
| igc | abentley: for WorkingTree's, it really needs to | 23:23 |
| igc | abentley: otherwise, every plugin needs to remember to switch it on | 23:23 |
| igc | and command | 23:23 |
| igc | abentley: IIRC, it used to live on the Tree API and default to True there too | 23:24 |
| abentley | igc: Not every plugin and command, just those that want the filtered form. | 23:24 |
| igc | abentley: but we backed out the change for .bzrrules, taking away historical storage of rules | 23:24 |
| abentley | igc: it's still a subtle enough behavior change that bugs it introduces might not be caught by our existing tests. | 23:25 |
| igc | abentley: in a sense, bzr has always used the internal form only | 23:26 |
| abentley | igc: I think that the parameter should exist on Tree, but should only affect Trees which have a filtered form. | 23:27 |
| igc | abentley: content filtering just means that what's in the tree is something else convenient for the user | 23:27 |
| igc | abentley: that sounds ok to me | 23:29 |
| igc | abentley: I'm pretty sure the text filtering issue was the only blocker wasn't it? | 23:31 |
| mwhudson | jelmer_: do you have a list of other branches that are failing to pull correctly? | 23:31 |
| abentley | igc: You gave me a tweak, and I upgraded it to resubmit because of that. | 23:31 |
| igc | abentley: I almost suggested last week that you land your change and we work together on the text filtering as a follow-up/known issue | 23:32 |
| jelmer_ | mwhudson: lp:~jelmer/samba/trunk, lp:~jelmer/openoffice/trunk and lp:~jelmer/openoffice/hosted | 23:32 |
| igc | abentley: given how little the text filtering is currently used | 23:33 |
| jelmer_ | mwhudson: beware of the last two though, they're both around 4.5Gb | 23:33 |
| igc | (and that's because we don't have branch-specific rules yet) | 23:33 |
| mwhudson | jelmer_: ah, the other two are mirrored branches | 23:33 |
| mwhudson | jelmer_: it's a bit crap that the openoffice/hosted got stuck again | 23:34 |
| mwhudson | jelmer_: did you push a lot of new revisions? | 23:34 |
| jelmer_ | mwhudson: about 100k | 23:34 |
| abentley | igc: I'd be happy to do that. | 23:34 |
| mwhudson | jelmer_: ok, i guess that qualifies as a yes | 23:35 |
| jelmer_ | mwhudson: :-) | 23:35 |
| igc | abentley: cool. Let's do that then because I don't think anything else I've seen in your patches so far will be affected | 23:36 |
| abentley | igc: I'm looking at the implementation of cmd_cat, and it doesn't pass filtered as a parameter to get_file_text. | 23:37 |
| igc | abentley: it's using the Tree API from memry, where that parameter doesn't exist | 23:38 |
| igc | abentley: RevisionTree API even | 23:38 |
| abentley | igc: It seems to be using revision trees everywhere, and in that case, it makes no sense to filter, because the file is already in the internal form. | 23:39 |
| igc | abentley: right, though the user can explicitly ask to see the output post-filtered | 23:40 |
| abentley | igc: Post filtered meaning the internal form? | 23:40 |
| igc | abentley: though, filtered then means "using configured filters", not historical filters | 23:41 |
| igc | abentley: the filtering can go 2 ways | 23:41 |
| igc | internal <-> external | 23:41 |
| igc | get_file_text() filters external -> internal | 23:42 |
| igc | abentley: in the case of cat, the filtering is the opposite way | 23:42 |
| abentley | igc: If "filtered" can mean two different states, do you think it would be clearer to refer to the desired state instead? | 23:43 |
| igc | abentley: perhaps | 23:44 |
| igc | abentley: the text at the top of bzrlib/filters/__init__.py might be of interest btw | 23:44 |
| abentley | igc: So this explains why no tests break even though CompositeTree doesn't support "filtered". Nothing which uses CompositeTree is also providing that parameter. | 23:49 |
| lifeless | abentley: we're going to need CT everywhere right? | 23:50 |
| abentley | lifeless: No. | 23:50 |
| lifeless | where won't we? | 23:50 |
| lifeless | RevisionTree's for instance, shouldn't they be returned as CT's now? | 23:51 |
| igc | abentley: probably because nothing wants the external form, only the internal | 23:51 |
| Peng_ | Possibly-dumb question: can branch references use relative paths? | 23:51 |
| lifeless | Peng_: not currently | 23:51 |
| mwhudson | Peng_: no | 23:51 |
| Peng_ | Darn. Thanks. | 23:51 |
| abentley | lifeless: Most cases where we're writing to the tree, and cases where we handle nesting directly for read operations. | 23:51 |
| Peng_ | That'd explain why I wasn't using a relative path already. :D | 23:51 |
| mwhudson | there was a thread about this on the bzr list semi-recently | 23:51 |
| lifeless | abentley: I'd have thought that e.g. 'bzr ls -R lp:twisted' should recurse. | 23:52 |
| abentley | lifeless: It probably should, but it's not on the list of commands I've committed to support. | 23:52 |
| lifeless | abentley: this comes back to my strong feeling we should be putting the support inside regular trees rather than an optional external construct which people need to remember to use | 23:53 |
| abentley | lifeless: I don't think that's practical. | 23:55 |
| lifeless | abentley: why not? | 23:55 |
| abentley | it makes everyone pay the cost of the feature, it makes recursion mandatory, it hides what's really going on, it makes the code trickier to debug. | 23:58 |
| abentley | It's an all-or-nothing sort of solution. We need an incremental one. | 23:59 |
| abentley | If we can't start somewhere, we'll never get finished. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!