| NfNitLoop | ()!&*(ULWDJKFW. Apparently git-svn doesn't always create the same commit IDs for things it's mapped from svn. | 02:37 |
|---|---|---|
| NfNitLoop | gaaaah. | 02:37 |
| NfNitLoop | I'm just going to have to fix bzr & bzr-svn to work with my repo, git-svn is making me want to stab someone. :p | 02:38 |
| NfNitLoop | Oh. Wow. That was way easier than I thought. | 02:50 |
| NfNitLoop | 1-line change in bzrlib. 2-line change in bzr-svn. Now I can check out my repo with files with backslashes in it. :D | 02:51 |
| fbond | Hi. Why does bzr init recursively scan the contents of the directory I run it in? | 03:36 |
| fbond | This directory happens to contain a huge tree of files that I'm not interested in versioning, so init looks like its hanging. strace showed me why. | 03:37 |
| gutworth | it assumes you want to version them :) | 03:37 |
| fbond | I would think that that wouldn't happen until I run bzr add. | 03:37 |
| NfNitLoop | Hrmmm. Odd. 'bzr branch <svn-branch>' gave me a 2.3GB directory. | 04:17 |
| NfNitLoop | a bit larger than the svn or git checkouts. | 04:18 |
| NfNitLoop | so then I bzr init-repo, and branch that branch into the shared repo. | 04:18 |
| NfNitLoop | and magically it's reduced to 1.4GB. | 04:18 |
| NfNitLoop | weeeeeird. | 04:18 |
| spiv | NfNitLoop: 'bzr pack && rm .bzr/repository/obsolete-packs/*' would probably have the same effect. | 04:26 |
| spiv | NfNitLoop: the bzr-svn import works incrementally (1000 revisions at a time) rather than doing it all in one transaction, and the reduces the effectiveness of the automatic packing (in the short term). The tradeoff is that if the import is interrupted it can be resumed, rather than needing to redo from start. | 04:27 |
| spiv | (Also some of the obsolete packs won't have been cleared out by the autopacking.) | 04:29 |
| NfNitLoop | aaaah. Yeah, I'd tried a pack but didn't rm obsolete-packs. | 04:32 |
| NfNitLoop | it's nice. a bzr-svn branch with full history is smaller than my svn checkout. :D | 04:32 |
| spiv | NfNitLoop: :) | 04:36 |
| NfNitLoop | So. To get this to work with my repo, which includes a file in its history with a \... | 04:36 |
| NfNitLoop | I had to remove checks for that character in bzrlib and bzr-svn. | 04:36 |
| whitley | hi all. I'm looking at the ignore tests (test_ignores.py, per_workingtree/test_is_ignored.py) and don't see any tests for '**/ignoreme.o' patterns or regexp patterns. | 04:36 |
| NfNitLoop | 3 lines changed total. | 04:36 |
| NfNitLoop | Should I put those on launchpad? Wondering what the ... ettiquette is there. | 04:37 |
| NfNitLoop | er. etiquette. :p | 04:38 |
| spiv | NfNitLoop: oh | 04:43 |
| spiv | NfNitLoop: so, that check is unfortunately intentional | 04:43 |
| spiv | NfNitLoop: It's true that the current format is technically capable of representing it safely, but there are interoperability issues with other versions of bzr and other formats that meant to have identical capabilities. | 04:44 |
| spiv | NfNitLoop: so unfortunately it's not as easy as a 3-line patch | 04:45 |
| spiv | NfNitLoop: and you will probably have issues if you use an unpatched bzr on this repo. | 04:45 |
| spiv | NfNitLoop: If the filename with the \ only exists in pretty old revisions, you might be able to safely do something like construct a repo that omits all revisions at and before that point | 04:47 |
| spiv | (i.e. those revisions would be a 'ghosts' in our jargon) | 04:47 |
| spiv | NfNitLoop: that would preserve all the same revision and file-ids, so bzr-svn would keep interoperating pretty happily unless you tried to access those old revisions. | 04:48 |
| NfNitLoop | how do you do that? | 04:48 |
| spiv | NfNitLoop: I think you'd need a script or a plugin to make that happen, post to the list and I'm sure someone can throw one together for you | 04:48 |
| NfNitLoop | oh. | 04:48 |
| spiv | NfNitLoop: unfortunately I don't have time to do so right now :/ | 04:48 |
| spiv | NfNitLoop: good luck | 04:49 |
| * spiv -> afk | 04:49 | |
| NfNitLoop | Hrmm, I don't quite understand what you mean by "interoperability issues with other versions of bzr and other formats that [are] meant to have identical capabilities". | 04:50 |
| === abentley1 is now known as abentley | ||
| NfNitLoop | I know that an unpatched repo might see the \ and throw an error. | 04:51 |
| NfNitLoop | But that's fine by me. I just want to use bzr wih my svn repo. :p | 04:51 |
| === rockstar` is now known as rockstar | ||
| NfNitLoop | Hrmm. | 06:31 |
| NfNitLoop | I seem to have accidentally pushed a repository onto the root of my shared repository. | 06:31 |
| NfNitLoop | Is there a way to undo that? | 06:31 |
| bob2 | pushed a /branch/ onto the root of your shared repository? | 06:46 |
| bob2 | if so, I think it is safe to just rm ~/repo/.bzr/branch | 06:48 |
| NfNitLoop | ah, ok, thanks! | 07:10 |
| bob2 | (backup first of course :) | 07:10 |
| NfNitLoop | that did it. :p | 07:14 |
| visik7 | how can I pick a commit made on a branch and put it in another branch ? | 10:41 |
| hmeland_ | visik7: Do a "cherrypick merge"; see the 81..82 example in "bzr help merge". | 10:50 |
| visik7 | ok thanks | 10:50 |
| abeaumont_ | is there any way to join a bzr-svn subtree in a bzr tree? | 13:08 |
| nomatter001 | hi | 13:31 |
| nomatter001 | is it somehow possible to get the working tree populated on an central server | 13:31 |
| nomatter001 | so that with a push i also get the working-files there? | 13:31 |
| Pilky | nomatter001: I believe there is a plugin that does a push and checkout | 13:34 |
| nomatter001 | Pilky: but a checkout doesn't do anything for me | 13:34 |
| Pilky | nomatter001: https://launchpad.net/bzr-push-and-update/ | 13:34 |
| nomatter001 | Pilky: the files are still just locally | 13:34 |
| Pilky | yeah you need to checkout the remote branch to the server | 13:35 |
| nomatter001 | Pilky: how do i do that? | 13:35 |
| Pilky | and then after each push update the working tree on the server | 13:35 |
| nomatter001 | Pilky: on the remote server is no bzr installed | 13:35 |
| Pilky | if your server is http://foo.com/repo then | 13:36 |
| Pilky | bzr checkout http://foo.com/repo http://foo.com/repo | 13:36 |
| Pilky | or however you access it | 13:36 |
| Pilky | either way you checkout the branch to the branch location | 13:36 |
| nomatter001 | Pilky: my problem is that i created the branch locally | 13:37 |
| Pilky | but you've pushed it to a server? | 13:37 |
| nomatter001 | Pilky: yes | 13:37 |
| Pilky | well that's a copy of the branch on that server | 13:37 |
| nomatter001 | Pilky: but now, how do i also get the working-tree onto the server? | 13:37 |
| Pilky | by checking out the branch on the server, to a location on the server | 13:38 |
| Pilky | are you coming from subversion to bzr? | 13:38 |
| nomatter001 | Pilky: i used svn a lil bit but i'm generally a beginner | 13:38 |
| Pilky | right, well think of it like this | 13:39 |
| Pilky | you have a branch, which you can think of as a blob which contains the full history | 13:39 |
| Pilky | if you push a branch somewhere then that is copied (unless it is stacked but we won't get into that) | 13:39 |
| Pilky | so there are two independent copies of the branch now | 13:39 |
| Pilky | if you delete the branch from your machine then the one on your server still exists | 13:40 |
| Pilky | a working tree is basically the physical files that you can work on | 13:40 |
| Pilky | in order to get a working tree from a branch that doesn't have one | 13:40 |
| Pilky | you need to checkout that branch | 13:41 |
| Pilky | which basically pulls the files out of the blob that represents your history and creates the individual files on disk | 13:41 |
| Pilky | that make sense? | 13:41 |
| nomatter001 | yes | 13:44 |
| nomatter001 | but how do i checkout the branch in itself on the server | 13:44 |
| nomatter001 | so that i have basically the same on the server as on my local disk | 13:45 |
| Pilky | well you just do what I said, at the moment your branch that has been pushed has no working tree so you need to checkout it out to the location of the branch so you do | 13:45 |
| Pilky | bzr checkout urltobranch urltobranch | 13:45 |
| Pilky | that will checkout the remote branch to the location of the remote branch | 13:45 |
| nomatter001 | ok thx i'll try | 13:46 |
| Pilky | then every time after that, after you push to the remote branch | 13:46 |
| Pilky | you need to update the remote branch too | 13:46 |
| Pilky | but if you use this push and update plugin (https://launchpad.net/bzr-push-and-update/) then every time you push, update will be called for you | 13:47 |
| nomatter001 | now i do get: sfp://... is not a local path | 13:47 |
| nomatter001 | so the checkout from remote to remote doesn't work | 13:47 |
| Pilky | hmm, not entirely sure then, I mean I haven't done this myself but theoretically from the commands it should work | 13:48 |
| Pilky | you'll probably be best askign one of the bzr devs | 13:49 |
| nomatter001 | Pilky: ok but how do i get to them? | 13:49 |
| Pilky | it seems jam wrote the push and update plugin, but he isn't online at the moment | 13:49 |
| Pilky | just look for people with these nicks: http://wiki.bazaar.canonical.com/IrcNicks | 13:50 |
| __monty__ | Can anyone tell me where ~/.bzr.log is written, in what module? | 14:02 |
| nomatter001 | Pilky: ok ic | 14:04 |
| nomatter001 | Pilky: thx so far | 14:05 |
| __monty__ | I understand that ~/.bzr.log is referred to as _trace_file in bzrlib, is this correct? | 14:38 |
| NfNitLoop | nomatter001: Populating remote working trees isn't supported generally. | 15:07 |
| nomatter001 | NfNitLoop: so there is no way to do it? | 15:17 |
| NfNitLoop | you can log in to the remote machine and do 'bzr checkout .' to create a working tree. | 15:18 |
| NfNitLoop | there may also be an option to push these days? Let me check... | 15:18 |
| NfNitLoop | yep, `bzr help push` says: The target branch will not have its working tree populated because this is both expensive, and is not supported on remote file systems | 15:19 |
| nomatter001 | NfNitLoop: so it's impossible? | 15:23 |
| nomatter001 | NfNitLoop: that it's expensive doesn't bother me | 15:23 |
| NfNitLoop | with bzr, yes. There are other tools that are more efficient for copying files. rsync/scp... | 15:23 |
| rubbs | nomatter001: I'm not sure what you are looking for but if you go to http://wiki.bazaar.canonical.com/BzrPlugins and look under publishing, it gives some plugins that can push and update remote dirs. | 15:23 |
| NfNitLoop | rubbs: Oh! Good to know. | 15:24 |
| rubbs | no prob. | 15:24 |
| rubbs | it's not a part of the core because of too many problems supporting remote systems. but if you have ssh access you can use most of the plugins IIRC | 15:25 |
| NfNitLoop | nomatter001: I think one of the reasons it's avoided is that it gets complicated fast if there are changes in the remote files, which requires doing merges, possibly including conflicts. | 15:25 |
| NfNitLoop | so you basically need to *read and write* the entire remote filesystem to do it safely. | 15:26 |
| rubbs | nomatter001: I think automirror might be what you are looking for: http://doc.bazaar.canonical.com/plugins/en/automirror-plugin.html | 15:27 |
| rubbs | nomatter001: if your looking to just upload the working dir and not worrying about all the history then check out "upload": http://doc.bazaar.canonical.com/plugins/en/upload-plugin.html | 15:28 |
| krisives | Do we have a formal retort to http://whygitisbetterthanx.com ? | 15:36 |
| NfNitLoop | http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html | 15:37 |
| NfNitLoop | There's that. | 15:37 |
| NfNitLoop | yeah, I read "why git is better than X" a while back and rolled my eyes at a lot of them. | 15:38 |
| rubbs | It seems to be out of date. | 15:40 |
| rubbs | it doesn't list what versions of each system they tested on. | 15:40 |
| rubbs | bzr doesn't seem to be that slow anymore | 15:40 |
| krisives | NfNitLoop: Agreed | 15:41 |
| krisives | IMO git is more complicated | 15:41 |
| NfNitLoop | WAY more complicated. | 15:43 |
| NfNitLoop | I was just lamenting in here yesterday about having to use git-svn for something. | 15:43 |
| rubbs | I also think that some of it is just wrong. like git's branching model is similar to the repo idea that bzr uses. No multiple directories with the same history or anything | 15:43 |
| === gutworth_ is now known as gutworth | ||
| NfNitLoop | I wanted to push my changes into a branch. So I had to tell git where my svn branches were. So it re-fetched all of svn history. And gave everything *new commit IDs*. Which meant my existing branch was no longer related to where I wanted to push it. | 15:44 |
| NfNitLoop | so I got to go become an expert in their rebase command to try to fix it. >.< | 15:44 |
| NfNitLoop | whereas with bzr-svn it would've just been "bzr svn-push <new-branch-location>" <3 | 15:45 |
| === beaumonta is now known as abeaumont_ | ||
| __monty__ | Where is ~/.bzr.log written? | 17:02 |
| gutworth | where in the code base? | 17:03 |
| __monty__ | Yeah | 17:03 |
| gutworth | bzrlib/trace.py I believe | 17:03 |
| fbond | How can I get bzr stats to map e-mail addresses to something more useful than "Unknown"? | 17:03 |
| __monty__ | gutworth: Is .bzr.log written in mutter? | 17:04 |
| gutworth | I don't know, is it :) | 17:05 |
| gutworth | ? | 17:05 |
| NfNitLoop | Hrmm, I always forget. How do I log "patches in this branch not in OtherBranchX?" | 17:08 |
| gutworth | bzr missing | 17:08 |
| NfNitLoop | aha, thanks. :) | 17:09 |
| NfNitLoop | I always try to fool with `bzr log -r <wacky Revisionspecs>` | 17:09 |
| __monty__ | gutworth: If you want to know, I think .bzr.log is written in push_log_file() , I don't really understand what mutter() does yet. | 17:12 |
| gutworth | I see _trace_file.write() in mutter()... | 17:14 |
| __monty__ | You're right. | 17:15 |
| __monty__ | But _trace_file originates from push_log_file() | 17:15 |
| __monty__ | gutworth: I'm trying to solve this error: https://bugs.launchpad.net/bzr/+bug/257170 ; Am I looking in the right place? | 17:21 |
| ubottu | Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed] | 17:22 |
| gutworth | __monty__: well, the arguments are printed in commands.py | 17:26 |
| __monty__ | gutworth: How did you find that, grepping? | 17:28 |
| gutworth | no, I remember | 17:30 |
| __monty__ | gutworth: Why is there a while loop instead of a for loop in run_bzr()? | 17:39 |
| gutworth | because it skips args in the loop | 17:39 |
| __monty__ | Can't you do that with for? | 17:41 |
| gutworth | no | 17:42 |
| gutworth | well, I suppose, but it would be uglier | 17:42 |
| __monty__ | gutworth: What do you think about this: http://python.pastebin.com/d9ad1c1a ? | 17:58 |
| gutworth | __monty__: it's ugly | 18:04 |
| gutworth | and not flexible | 18:04 |
| __monty__ | :-( | 18:05 |
| __monty__ | What are your criteria? | 18:05 |
| gutworth | why do you care so much? | 18:05 |
| __monty__ | I don't really do. | 18:06 |
| __monty__ | gutworth: Where should I print the version number in .bzr.log? | 18:15 |
| gutworth | before the arguments? | 18:17 |
| __monty__ | bzr arguments: [u'VERSION', u'...', u'...'] like this, gutworth? | 18:29 |
| jwhitley | hi all, I'm not finding any tests for '**/...' or regexp ignore patterns. Am I just missing them, or do they need coverage? not in test_ignores.py or test_is_ignored.py | 18:36 |
| jwhitley | I'm about to start working on https://bugs.launchpad.net/bzr/+bug/428031, and can add tests for those cases while I'm at it... | 18:37 |
| ubottu | Ubuntu bug 428031 in bzr ".bzrignore should support exclusions" [Medium,Confirmed] | 18:37 |
| jwhitley | or perhaps I'll put it another way: is there some notable obstacle to having test_ignores/test_is_ignored cover '**/...' or regexp patterns? | 18:43 |
| gutworth | __monty__: like that | 18:45 |
| gutworth | jwhitley: can't hurt to have more tests | 18:46 |
| __monty__ | gutworth: So I just add the version as if it's an argument? | 18:46 |
| === abentley1 is now known as abentley | ||
| gutworth | __monty__: how about the line before | 18:46 |
| __monty__ | gutworth: Bazaar version: x.x.x ? | 18:48 |
| gutworth | sure | 18:50 |
| __monty__ | And in which function, module should I put it? | 18:50 |
| gutworth | how about above bzr arguments? | 18:51 |
| __monty__ | ? | 18:51 |
| jwhitley | gutworth: right, then. I'll have a go at fixing up ignore test coverage while I'm at it... | 18:52 |
| gutworth | __monty__: in commands.py | 18:53 |
| __monty__ | gutworth: right above trace.mutter(...) ? | 18:54 |
| gutworth | yep | 18:55 |
| __monty__ | gutworth: And I do this via a call to trace.mutter() ? | 18:56 |
| gutworth | yes | 18:57 |
| jwhitley | ah, test_globbing has the ** and regexp coverage, but not related to ignores. | 18:57 |
| __monty__ | gutworth: To retrieve the bzr version, can I use bzrlib.__version__ | 19:06 |
| __monty__ | ? | 19:06 |
| gutworth | sure | 19:07 |
| Peng | __monty__: Yeah, using bzrlib.__version__ or bzrlib.version_string (which are completely equivalent) is standard practice. | 19:25 |
| __monty__ | I get '2.1.0dev5' if I print bzrlib.__version__ , this is correct right? | 19:26 |
| Peng | __monty__: Uh-huh. | 19:31 |
| __monty__ | Peng: If I wasn't clear enough, the dev... is only printed for my version, not for every version right? | 19:32 |
| Peng | __monty__: Alphas, betas, release candidates and releases are indeed different. | 19:34 |
| __monty__ | Peng: Could you check my solution to this: https://bugs.launchpad.net/bzr/+bug/257170 ? | 19:35 |
| ubottu | Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed] | 19:35 |
| Peng | __monty__: I'm not qualified to review tests, but sure. | 19:36 |
| __monty__ | How can I make a diff of my change? (it's only one line so I could just write it here) | 19:37 |
| Peng | __monty__: Well, "bzr diff". | 19:38 |
| __monty__ | Peng: And I just copy the output? | 19:38 |
| gutworth | push a branch | 19:39 |
| Peng | Yeah. You'll have to do that eventually anyway. | 19:40 |
| __monty__ | To launchpad? | 19:40 |
| gutworth | yes | 19:41 |
| Peng | Or you could push it elsewhere and then have LP mirror it, but not many people bother with that. :D | 19:41 |
| gutworth | __monty__: have you read http://doc.bazaar.canonical.com/developers/? | 19:42 |
| __monty__ | Partly | 19:42 |
| __monty__ | Should I push to lp:username/bzr/giveback, or .../giveback/somedescriptivenamehere ? | 20:02 |
| NfNitLoop | lp:~username/bzr/descriptive-branch-name-but-not-too-long-like-this-one | 20:03 |
| NfNitLoop | ;) | 20:03 |
| NfNitLoop | just from what I've seen. | 20:03 |
| NfNitLoop | maybe an actual dev has other preferences. | 20:03 |
| __monty__ | So no 'giveback' as suggested in HACKING.txt ? | 20:03 |
| NfNitLoop | oh. Ignore me then. :) | 20:05 |
| gutworth | it doesn't matter hugely | 20:05 |
| __monty__ | NitLoop: I was just asking to be sure. | 20:06 |
| __monty__ | gutworth: What is the custom? | 20:06 |
| Peng | __monty__: Look over https://code.launchpad.net/bzr to see what other people do. | 20:07 |
| Peng | __monty__: The custom is to name it something descriptive and useful to you, like "log-bzr-version" or somesuch. | 20:07 |
| Peng | __monty__: Some people like to include the version number it's intended for in the branch name. | 20:08 |
| NfNitLoop | looks like some others include the bug number. | 20:08 |
| Peng | Ah, right, forgot that. | 20:08 |
| NfNitLoop | but that's a bit redundant since you can tie it to a bug. | 20:09 |
| NfNitLoop | via launchpad. | 20:09 |
| Peng | BTW, you can do "bzr commit --fixes lp:1234" to add a little meta data tying the revision to the bug. | 20:09 |
| NfNitLoop | ooooh, cool. | 20:09 |
| Peng | It's not actually very *useful*, though. But LP's branch scanner will automatically link the branch and bug together when it comes across it./ | 20:10 |
| __monty__ | So I just do a commit --fixes lp:257170 to link the branch to this https://bugs.launchpad.net/bzr/+bug/257170 ? | 20:11 |
| ubottu | Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed] | 20:11 |
| rubbs | yes | 20:11 |
| rubbs | it will link up to that bug... | 20:11 |
| __monty__ | Ok, thanks. | 20:11 |
| rubbs | so when you view the bug on lp you can see "related branches" | 20:11 |
| rubbs | also if you are on the branch's page, you can see linked bugs | 20:12 |
| __monty__ | I get 'pointless commit' if I do a commit --fixes lp:257170 , what should I do, commit --unchanged ? | 20:16 |
| gutworth | have you made any changes? | 20:16 |
| gutworth | generally you commit the --fixes with any change you've made | 20:17 |
| __monty__ | I already commited my changes. | 20:17 |
| Peng | __monty__: it's not worth trying to retroactively do it, then. | 20:17 |
| Peng | __monty__: But you should keep it in mind for the future. :) | 20:18 |
| __monty__ | Oh ok | 20:18 |
| Peng | Honestly, I forget --fixes most of the time. :) | 20:18 |
| rubbs | __monty__: Peng is correct. It's not worth retroactivly doing, but you do --fixes at the commit. | 20:18 |
| __monty__ | Should I propose my branch for merging? | 20:24 |
| Peng | __monty__: If it's ready, yes. | 20:26 |
| __monty__ | It solves the 'bug' so I believe it's ready. | 20:27 |
| __monty__ | What should the Target Branch be? | 20:31 |
| Peng | __monty__: What is it a branch of? lp:bzr, lp:bzr/2.0? Whichever. | 20:32 |
| Peng | __monty__: I mean, the target branch should be what it's a branch of. | 20:32 |
| __monty__ | Should the 'Cover letter' be written in Initial Comment ? | 20:37 |
| __monty__ | And what should I enter in Reviewer and Review type ? | 20:46 |
| Peng | __monty__: For reviewer and review type, just go with the default. | 20:53 |
| Peng | __monty__: for the cover letter, um, yes? | 20:53 |
| __monty__ | And review type may be empty? | 20:53 |
| Peng | __monty__: That's the default. :D | 20:54 |
| rubbs | __monty__: yeah, just put in your cover letter in the initial comment section. the reviewer and reviewer type can be left blank because you are not a reviewer. They are not manditory fields | 21:00 |
| __monty__ | Thanks everyone for all the help. :-) | 21:05 |
| __monty__ | Goodnight. | 21:05 |
| rubbs | night | 21:08 |
| __monty__ | One more question, how do I create a patch with bazaar? | 21:09 |
| rubbs | __monty__: do you mean like diff? you can use -p and specify old and new file names to create a patch. see "bzr help diff" | 21:12 |
| __monty__ | Ok thank you. | 21:12 |
| Peng | __monty__: "bzr send" can create a merge directive, which includes all of the metadata as well. | 21:12 |
| Peng | __monty__: If you're talking about a Launchpad merge proposal, LP will create a diff automatically. | 21:12 |
| __monty__ | It's to add a comment to the page of the bug with the patch. | 21:13 |
| rubbs | not neccissary. LP will do that for you | 21:13 |
| __monty__ | Oh, ok | 21:14 |
| rubbs | Necessary* | 21:14 |
| __monty__ | Well, goodnight then. | 21:14 |
| rubbs | night. | 21:14 |
| Peng | _ -- darn, left. | 21:15 |
| rubbs | haha. | 21:15 |
| Peng | I was just gonna say "good night". | 21:16 |
| Pilky | Peng: how rude of you not to ;) | 21:16 |
| * Peng cries | 21:16 | |
| Pilky | Peng: don't worry, you can say good night to me when I go offline | 21:19 |
| Pilky | though that won't be for another few hours, spending the evening in photoshop | 21:19 |
| Peng | Pilky: Pre-emptively, "Good night, Pilky". | 21:20 |
| Pilky | shame monty left though, what I'm working on might have interested him | 21:21 |
| Pilky | http://dropbox.mcubedsw.com/skitchpics/BazaarX%20Commit.png | 21:21 |
| rubbs | Pilky: that's pretty nice looking... what is it? | 21:22 |
| Pilky | mockup for BazaarX, a bzr GUI I'm making for the Mac | 21:23 |
| Pilky | I've restarted the project enough times already | 21:24 |
| Peng | Next someone needs to make a GUI for the iPhone. ;D | 21:24 |
| Pilky | so I'm going through and mocking up the entire UI before I write any more code | 21:24 |
| Pilky | annoyingly just as everyone on the Mac is switching to Bzr, Git or Hg, there were two really good GUI clients for Svn released so I'm wanting to build an open source client of a similar calibre | 21:25 |
| rubbs | Peng: you may be joking, but I thought about the possibility of at least a diff and log checker for my Android phone. Might even do it too | 21:25 |
| Pilky | for comparison: http://www.versionsapp.com/ and http://zennaware.com/cornerstone/ | 21:26 |
| Pilky | Peng: doubt it would be that useful :p | 21:26 |
| rubbs | Pilky: gotcha. sounds like a good idea. If I had a Mac to play on I'd thikn about helping out. but alas.. :( | 21:26 |
| Pilky | iPhone optimised UI for launchpad though | 21:26 |
| Pilky | that would be useful | 21:26 |
| Pilky | might try it when I start my crazy rocketship project | 21:27 |
| rubbs | agreed... a mobile version of lp could be very useful. | 21:27 |
| Pilky | (I'm going to be building an alternate UI for launchpad) | 21:27 |
| Pilky | which I swear is the last open source project I'm going to commit to, otherwise I won't have time to work on the code that brings in the money :p | 21:28 |
| Peng | Pilky: Get Canonical to hire you. ;-D | 21:28 |
| Pilky | heh, well these are mostly side projects that I'm doing to help my main stuff | 21:29 |
| NfNitLoop | Pilky: Heh. that screenshot's so nice I wanted to grab the sliders and play around with it. :p | 21:55 |
| Pilky | heh | 21:55 |
| NfNitLoop | I do so little development on my mac, though... | 21:57 |
| NfNitLoop | I mean, I'll be typing on my mac. | 21:57 |
| NfNitLoop | but it's into an ssh session somewhere else. | 21:57 |
| Pilky | heh | 21:57 |
| NfNitLoop | The only local dev. work I do is on my linux box here at work. | 21:58 |
| Pilky | well all my dev work is done on my mac so a desktop client for bzr would help me a lot | 21:58 |
| NfNitLoop | *nod* | 21:58 |
| NfNitLoop | Mostly I was just QQing that I wouldn't get to use it. :) | 21:58 |
| === khmarbaise_ is now known as khmarbaise | ||
| Pilky | well it likely won't be finished for a long time :p | 22:00 |
| Pilky | at the moment it is just consisting of mockups | 22:00 |
| NfNitLoop | aah. | 22:00 |
| Pilky | anyway, time to get offline for the night | 22:05 |
| Pilky | Peng: if you want to do the honours :p | 22:05 |
| Peng | Pilky: Good night. :D | 22:06 |
| === Helheim_ is now known as Helheim | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
