| aboSamoor | I am trying to add svn folders to bzr, I got this message "bzr: ERROR: Permission denied: ".": PROPFIND request failed on '/svn/trunk'" | 00:57 |
|---|---|---|
| lifeless | see my reply in #launchpad | 01:08 |
| === Spaz is now known as Paradoxataur | ||
| === AfC1 is now known as AfC | ||
| Peng_ | Err.. bzr just did an autopack. .bzr.log said it was packing from 14 packs to 10, but instead it packed them down to...3. I don't get it. | 03:55 |
| Peng_ | (I mean, it was right about there being 14 initially.) | 03:56 |
| lifeless | Peng_: it lied | 09:08 |
| lifeless | Peng_: please file a bug | 09:08 |
| lifeless | Peng_: (what it really meant was 'all but two of the packs needs to be combined' -> 3 (its simpler and more efficient than the original code | 09:09 |
| lifeless | but the debug output is the original plan of what would happen | 09:09 |
| Peng_ | Oh. | 09:15 |
| Peng_ | It should've combined them into 2 packs anyway. It left one with only like 2 revisions in it. :\ | 09:17 |
| lifeless | Peng_ well, could be a bug | 09:23 |
| Peng_ | Wait...what do you mean? It was originally going to leave 10 packs, but changed its mind after writing the debug message? | 09:24 |
| Peng_ | Well, I filed bug 295486. Kinda crappy title though. | 09:25 |
| ubottu | Launchpad bug 295486 in bzr "Autopack's debug output is wrong about how many packs will be left" [Undecided,New] https://launchpad.net/bugs/295486 | 09:25 |
| Peng_ | lifeless: Not to be a stalker, but you seem to have identical branches at lp:~lifeless/+junk/bzr-index2 and lp:~lifeless/+junk/index2. | 09:51 |
| === jszakmeister|awa is now known as jszakmeister | ||
| fullermd | Peng_: Don't try and act innocent. We all saw you checking out his branches. | 10:30 |
| === jszakmeister is now known as jszakmeister|awa | ||
| RedLizard | What is usually done with a feature branch once the feature is stable and has been merged into the trunk? I don't want it to clutter the branch namespace for all eternity, yet I do want it available for all eternity. | 13:50 |
| LarstiQ | RedLizard: I usually do nothing to it, or move it out of the way. | 13:54 |
| yml | Hello, I am having some hard time to understand how to make bzr happy after a big reorganisation in my project. | 13:54 |
| RedLizard | LarstiQ: i would like to mark it as "closed for development" in some way | 13:55 |
| LarstiQ | RedLizard: mv it to done/ ? | 13:55 |
| yml | In fact I have moved/rename some folder in the terminal an now I try to make bzr aware of this modification | 13:55 |
| LarstiQ | yml: bzr mv --after oldname newname | 13:56 |
| LarstiQ | yml: this may be a little tricky if you have also done renames of children of that directory, it is doable but a bit more work than ideal | 13:56 |
| yml | LarstiQ: thanks I am going to try this | 13:56 |
| yml | LarstiQ: I have not done any renaming of the children | 13:57 |
| RedLizard | LarstiQ: that should work, i think | 13:57 |
| LarstiQ | yml: good :) | 13:57 |
| yml | LarstiQ: bzr mv --after django_glue/* projects/simple_project/ | 13:57 |
| yml | bzr: ERROR: Could not move to simple_project: projects/simple_project is not versioned. | 13:57 |
| LarstiQ | RedLizard: ime that is enough to clear the namespace isssue. | 13:58 |
| LarstiQ | yml: are you sure that is what you want? | 13:58 |
| LarstiQ | yml: could you describe the rename you did? | 13:58 |
| RedLizard | LarstiQ: optimally, i'd like the branch to be destroyed, and its history contained in the history of the trunk, available by "zooming in" on the merge commit | 13:59 |
| LarstiQ | RedLizard: if not, you can always delete a branch, since it's revisions are all merged into trunk, you can always recreate it when necessary | 13:59 |
| LarstiQ | RedLizard: but why bother? | 13:59 |
| LarstiQ | the burden of keeping around old branhces is very low | 13:59 |
| yml | Bzr was aware of a folder named django-glue in the root of my bzr directory then I did mv django_glue projects/simple_project | 14:00 |
| LarstiQ | yml: right, so it looks to me that should be 'bzr mv --after django_glue projects/simple_project' then | 14:00 |
| RedLizard | LarstiQ: because otherwise, i'd have to keep my branch names unique for all eternity | 14:00 |
| LarstiQ | yml: without the /* wildcard, that would be moving the children of django_glue, not django_glue itself | 14:00 |
| RedLizard | LarstiQ: i can't call my branches 'test' or something similar | 14:01 |
| yml | LarstiQ: bzr mv --after django_glue projects/simple_project | 14:01 |
| yml | bzr: ERROR: Could not move to simple_project: projects/simple_project is not versioned. | 14:01 |
| yml | same thing | 14:01 |
| LarstiQ | RedLizard: eh, a branch called 'test' imo is not worthy of staying around, nuke it :) | 14:01 |
| LarstiQ | yml: what version of bzr are you using? and is projects/ versioned? | 14:01 |
| RedLizard | LarstiQ: but the history will still be available in the trunk? great :) | 14:01 |
| LarstiQ | RedLizard: yes, absolutely | 14:02 |
| RedLizard | :) | 14:02 |
| yml | no project is not yet versionned | 14:02 |
| LarstiQ | `bzr branch trunk -r tip_revision_of_test resurrected-test` to bring it back | 14:02 |
| yml | and I amusing bzr : Bazaar (bzr) 1.3.1 | 14:03 |
| LarstiQ | yml: did projects/ previously exist, or did you mkdir it for this reorginasation? | 14:03 |
| yml | I mkdir project | 14:04 |
| yml | for this reorganisation | 14:04 |
| LarstiQ | yml: try 'bzr add --no-recurse projects/' before you do the mv --after | 14:05 |
| yml | same thing | 14:06 |
| yml | I also try to bzr add projects/simple_project before doing the mv but it also didn't work | 14:07 |
| LarstiQ | right, that you do not want to do | 14:08 |
| LarstiQ | yml: in my small test it worked, but let me try with 1.3.1 instead of 1.9 | 14:08 |
| yml | LarstiQ: Is there an easy way to update to 1.9 on ubuntu | 14:10 |
| yml | by easy I mean sudo apt-get install ... :-) | 14:10 |
| LarstiQ | yml: yes, there is | 14:11 |
| jelmer | 'morning yml, LarstiQ | 14:11 |
| LarstiQ | moguh jelmer | 14:11 |
| yml | ok so might be an option if you found out that it is not working with 1.3.1 | 14:11 |
| LarstiQ | yml: use the bzr ppa, https://launchpad.net/~bzr/+archive | 14:11 |
| LarstiQ | yml: just a moment though | 14:12 |
| LarstiQ | yml: I'll give you my test script, maybe what I'm doing is too simplistic and doesn't actually cover your case | 14:12 |
| yml | ok | 14:13 |
| LarstiQ | yml: indeed, 1.5 and up succeed where 1.3 does not | 14:16 |
| LarstiQ | yml: http://rafb.net/p/AFkUPw64.html fwiw | 14:17 |
| yml | LarstiQ: Excellent news | 14:18 |
| yml | LarstiQ: so now I just have to move to the latest bzr | 14:19 |
| yml | does bzr-svn is working on 1.9 ? | 14:19 |
| jelmer | yml: yes, with bzr-svn 0.4.14 | 14:19 |
| LarstiQ | jelmer: oh! you did a release, sweet! | 14:20 |
| yml | jelmer: How can I install it on ubuntu ? | 14:20 |
| yml | apt-get install ? | 14:20 |
| jelmer | I don't think it's been uploaded to the PPA yet or synced from Debian | 14:21 |
| LarstiQ | the ppa has 0.4.13-2 | 14:21 |
| jelmer | you may be able to install the Debian package or otherwise install from source | 14:21 |
| yml | LarstiQ: thank you very much for your help | 14:30 |
| yml | 1.9 solve my issue | 14:30 |
| yml | Is it just me and my happyness or does bzr status is faster ? | 14:31 |
| yml | jelmer: do you have an idea when the PPA will be updated? | 14:31 |
| LarstiQ | yml: there have been improvements to status speed between 1.3 and 1.9, so that's entirely possible :) | 14:32 |
| yml | Thank you so much for your effort in bzr | 14:35 |
| yml | for some reason that I cannot explain I just feel good with it | 14:35 |
| yml | the only thing missing to me at the moment is a bzr-git | 14:36 |
| yml | it is such a pain for me each time I have to work with git | 14:36 |
| jelmer | yml: you may want to subscribe to bug 293009 | 14:37 |
| ubottu | Launchpad bug 293009 in bzr-svn "Bzr-svn conflicts with bzr in the PPA" [Undecided,New] https://launchpad.net/bugs/293009 | 14:37 |
| yml | jelmer: I am actually on hardy | 14:41 |
| yml | but I get the same error message when I try to apt-get install bzr-svn | 14:42 |
| jelmer | the packages are always uploaded for all ubuntu releases at the same time | 14:42 |
| yml | thank I will wait for its resolution | 14:44 |
| Flyser_ | Hi. is it possible to use bzr for my local repository and then push it to a remote svn server? | 15:05 |
| === abadger19991 is now known as abadger1999 | ||
| jelmer | Flyser_, hi | 15:16 |
| jelmer | Flyser_, yes | 15:16 |
| jelmer | jszakmeister|awa, hi | 17:16 |
| RedLizard | How can I restore a branch that I merged into some other branch in the past? | 18:47 |
| luks | RedLizard: get the latest revision number of the merged branch and run: bzr branch -rX orig new | 18:49 |
| RedLizard | and how do I get the latest revision number of the merged branch? | 18:51 |
| RedLizard | it doesn't appear in `bzr log` | 18:51 |
| luks | it should, if the branch was merged | 18:53 |
| luks | (and you don't have bzr log aliased to something like bzr log --short) | 18:53 |
| RedLizard | http://pastebin.com/m60c521ed | 18:54 |
| RedLizard | no revision number there | 18:54 |
| LarstiQ | RedLizard: revid:redlizard@ruud0-20081108134022-03073670ea55866a | 18:57 |
| LarstiQ | RedLizard: what version of bzr is that? | 18:57 |
| LarstiQ | or, what custom logformatter are you using? | 18:57 |
| luks | what version of bzr is it? | 18:57 |
| RedLizard | 0.11.0 | 18:57 |
| LarstiQ | right :) | 18:57 |
| LarstiQ | RedLizard: etch? | 18:57 |
| RedLizard | yup | 18:58 |
| * LarstiQ hasn't seen that log output in a loooong time | 18:58 | |
| luks | me neither :) | 18:58 |
| luks | I was confused by the merged line | 18:58 |
| LarstiQ | RedLizard: anyway, `bzr branch -r revid:redlizard@ruud0-20081108134022-03073670ea55866a resurrect` | 18:58 |
| LarstiQ | RedLizard: veel plezier :) | 18:58 |
| LarstiQ | RedLizard: (fwiw, we're up to 1.9 now) | 18:59 |
| * RedLizard wonders what gave him away | 18:59 | |
| LarstiQ | RedLizard: 'gemerged' | 18:59 |
| RedLizard | ah :) | 18:59 |
| RedLizard | it works | 19:01 |
| RedLizard | good :) | 19:02 |
| RedLizard | Is there any reason I should _really_ upgrade from 0.11.0? | 19:05 |
| LarstiQ | If you're not interacting with anyone else, 0.11 will work fine. | 19:06 |
| LarstiQ | That is, other bzr branches might be in a format 0.11 does not understand. | 19:06 |
| LarstiQ | And, if you're asking for help, it pays to mention the version you're using :) | 19:07 |
| RedLizard | yes, i noticed | 19:07 |
| RedLizard | (stupid debian testing on development servers :p) | 19:07 |
| LarstiQ | hmm, isn't testing lenny by now? | 19:08 |
| RedLizard | yes | 19:08 |
| LarstiQ | that should have bzr 1.5 | 19:09 |
| RedLizard | it does | 19:09 |
| LarstiQ | which, for this discussion, has a logformat that looks more familiar to us ;) | 19:09 |
| RedLizard | are the ubuntu packages on launchpad debian etch compatible? | 19:12 |
| LarstiQ | in the ppa? I believe not | 19:13 |
| LarstiQ | RedLizard: do you need a system wide bzr? Or is running from source good enough? | 19:14 |
| LarstiQ | RedLizard: 1.5 is in etch-backports fwiw | 19:14 |
| luks | etch-backports has 1.5 | 19:14 |
| luks | he | 19:14 |
| * luks is too slow | 19:15 | |
| RedLizard | LarstiQ: yeah, but then i'd get the entire backports repository | 19:15 |
| LarstiQ | RedLizard: personally, I run bzr from ~/src/bzr/<version>/bzr | 19:16 |
| RedLizard | hm, given that bzr depends only on python, the ubuntu packages will probably work fine on etch | 19:18 |
| * RedLizard tries | 19:18 | |
| luks | it contains compiled code | 19:18 |
| LarstiQ | and the packaging standards might be different, say python-central | 19:19 |
| === Toksyuryel` is now known as Toksyuryel | ||
| luks | you might have better luck just dpkg -i the deb from backports | 19:19 |
| RedLizard | why doesn't launchpad contain a debian repos as well, by the way? | 19:20 |
| strk | how to release al stale lock ? | 19:20 |
| strk | held by strk@gnash on host gnash [process #32194] | 19:20 |
| luks | bzr break-lock | 19:20 |
| strk | thx | 19:21 |
| RedLizard | hm, the ubuntu package doesn't work :( | 19:21 |
| LarstiQ | RedLizard: that is something that may happen in the future, but it requires buildd maintenance per suite. | 19:22 |
| LarstiQ | RedLizard: as well as the entire archive. | 19:23 |
| RedLizard | true | 19:25 |
| LarstiQ | RedLizard: so, I'd either try the etch backports .deb, or download and unpack a tarball, and run from that | 19:26 |
| RedLizard | LarstiQ: actually, i think i will build my own debian package | 19:26 |
| LarstiQ | ok :) | 19:27 |
| RedLizard | will `bzr branch` respect the repos format of the origin? | 19:30 |
| LarstiQ | RedLizard: if it can, yes. | 19:30 |
| LarstiQ | so branching from 0.11, hack hack, 0.11 should be able to pull the changes back | 19:31 |
| LarstiQ | RedLizard: just don't `bzr upgrade` it with 1.9 :) | 19:31 |
| RedLizard | LarstiQ: of course | 19:31 |
| LarstiQ | or branch it into a shared repo that uses a different format | 19:31 |
| RedLizard | hm, you really have to be quite careful when working together using different bzr versions | 19:33 |
| RedLizard | especially if you don't use a single repository for everything | 19:34 |
| * LarstiQ blinks | 19:35 | |
| LarstiQ | RedLizard: what do you mean? Having one repository for all your branches would make collaborating with older clients almost impossible. | 19:35 |
| LarstiQ | RedLizard: do note 0.11 is over 2 years old (roughly half the projects lifetime) and pre 1.0 | 19:37 |
| RedLizard | LarstiQ: unless the repository is in an old format | 19:37 |
| LarstiQ | RedLizard: which then makes other things impossible, like, say, bzr-svn | 19:37 |
| RedLizard | LarstiQ: so, the only solution is to make sure everyone uses the latest version at all times? | 19:38 |
| jelmer | RedLizard, the current default format has been supported since version 0.92, which is about a year old | 19:39 |
| LarstiQ | RedLizard: no, if you have one repository per project (which is good practice anyway), you should have an easy time of staying compatible with the least capable clients that work on that project | 19:39 |
| LarstiQ | RedLizard: that should reduce the friction to a level of not having to think about it | 19:39 |
| RedLizard | LarstiQ: good point | 19:41 |
| RedLizard | jelmer: good, that makes things easier... getting everyone to run >= 0.92 looks reasonable | 19:41 |
| LarstiQ | RedLizard: if you just have standalone branches, the only point where you run into trouble is by running upgrade yourself. | 19:41 |
| LarstiQ | RedLizard: but yeah, there is room for error | 19:44 |
| RedLizard | LarstiQ: not much if the default format is quite old | 19:45 |
| LarstiQ | RedLizard: right, in default cases you're safe | 19:45 |
| LarstiQ | RedLizard: but it's still possible to have a non-default repo, branch something old into that, work, try to get it back in, and notice the format got upgraded when you branched it | 19:46 |
| RedLizard | LarstiQ: won't it be saved in the default format again when merging it back in? | 19:47 |
| LarstiQ | RedLizard: if it's compatible, yeah. Not so when you are trying to stuff rich-root in non-rich-root | 19:48 |
| LarstiQ | </gripe> | 19:48 |
| * LarstiQ has some dinner and goes off to a verdiepingsfeetsje | 19:48 | |
| LarstiQ | modulo spelling bugs | 19:48 |
| RedLizard | have fun | 19:49 |
| LarstiQ | thanks | 19:49 |
| RedLizard | How can I init a branch on a remote server? | 19:57 |
| Kinnison | bzr init sftp://blahblahblah | 19:58 |
| Kinnison | :-) | 19:58 |
| LarstiQ | RedLizard: bzr init remote/path, or (my preference) work locally and publish changes when you have them | 19:58 |
| LarstiQ | Kinnison! | 19:58 |
| LarstiQ | Kinnison: how are you? | 19:58 |
| Kinnison | LarstiQ: Good thanks, busy busy busy :-) | 19:58 |
| RedLizard | bzr: ERROR: sftp://$PATH/.bzr/ is not a local path. | 19:58 |
| LarstiQ | Kinnison: that explains the not having seen you in a while ;) | 19:59 |
| Kinnison | LarstiQ: well that, and not going to any ubuntu/canonical confs due to lack of cash :-) | 19:59 |
| LarstiQ | RedLizard: yeah, I may have fixed that post 0.11 | 19:59 |
| RedLizard | LarstiQ: this is using 1.5 | 19:59 |
| * LarstiQ blinks | 19:59 | |
| LarstiQ | RedLizard: do you have paramiko installed? | 20:00 |
| RedLizard | LarstiQ: yes | 20:00 |
| RedLizard | LarstiQ: i do have a bazaar config file automatically created with 0.11, if that matters | 20:00 |
| LarstiQ | RedLizard: it works for me, what exact command did you try? (~/src/bzr/1.5/bzr init sftp://localhost/tmp/hagedis in my case) | 20:01 |
| RedLizard | LarstiQ: which, on inspection, does not contain anything relevant | 20:01 |
| RedLizard | LarstiQ: update: it gives me that error message, but it has in fact succeeded | 20:02 |
| RedLizard | LarstiQ: that is, on trying it a second time (unmodified), i get: | 20:02 |
| RedLizard | bzr: ERROR: Already a branch: "sftp://10.0.2.100/home/redlizard/repo". | 20:02 |
| RedLizard | LarstiQ: also, i forgot: i init-repo'd that directory just before init'ing it | 20:03 |
| LarstiQ | I recall old code trying to open a workingtree on the branch that just got inited, even when remote. It sounds roughly like that. | 20:03 |
| LarstiQ | RedLizard: ah. | 20:03 |
| LarstiQ | RedLizard: was that a mistake, or did you conciously do it that way? | 20:05 |
| RedLizard | LarstiQ: i did it conciously | 20:05 |
| LarstiQ | ok, in that case, why? :) | 20:05 |
| * LarstiQ files a bug that co-locating a branch and a shared repo remotely gives a confusing message | 20:06 | |
| LarstiQ | RedLizard: it is not a normal thing to do | 20:06 |
| RedLizard | LarstiQ: really? I thought it is a common optimization | 20:06 |
| RedLizard | LarstiQ: appearantly i misunderstood something; what exactly IS the common optimization using init-repo? | 20:07 |
| LarstiQ | RedLizard: the optimization only helps if you store multiple branches in a repository, at which point having the root of repo _also_ be a branch is weird. | 20:08 |
| LarstiQ | RedLizard: bzr init-repo sftp://host/repo; bzr init sftp://host/repo/branch; | 20:08 |
| RedLizard | LarstiQ: i use (read: am planning to use) the "nested branches" layout | 20:09 |
| RedLizard | LarstiQ: in which case having the shared repo also being the root branch sounds logical | 20:10 |
| LarstiQ | RedLizard: it could be. I still doubt it. | 20:10 |
| RedLizard | LarstiQ: what's so strange about it? | 20:11 |
| LarstiQ | RedLizard: the relation of the branch at the root to the other branches. | 20:12 |
| RedLizard | LarstiQ: otherwise, i would have /host/project (a --no-trees repo) containing only a directory trunk (a branch) containing other branches (recursively) | 20:12 |
| RedLizard | *containing only a directory "trunk" | 20:12 |
| LarstiQ | RedLizard: ah, I think I see what is going on here. | 20:13 |
| LarstiQ | RedLizard: what branches are in trunk/ then? | 20:14 |
| RedLizard | LarstiQ: feature branches, probably | 20:14 |
| RedLizard | LarstiQ: see section 10.2.2 of the user guide | 20:14 |
| LarstiQ | RedLizard: why wouldn't they be siblings of trunk, instead of children? | 20:14 |
| LarstiQ | RedLizard: just a moment, still filing that bug | 20:15 |
| RedLizard | LarstiQ: because they are created from trunk, and will ultimately be merged back into the trunk (a clear parent-child relation) | 20:16 |
| RedLizard | LarstiQ: and child objects residing in the parent directory is a Good Thing from a logical standpoint | 20:18 |
| LarstiQ | RedLizard: hmja. I disagree about there existing a parent/child relationship, but I see your point. | 20:19 |
| * LarstiQ looks at the user guide | 20:19 | |
| RedLizard | LarstiQ: permanent forks (say, splitting off 2.6 (the new unstable) from 2.4 (stable)) would be siblings of trunk | 20:19 |
| RedLizard | LarstiQ: which, come to think of it, is a good reason not to have trunk equal the repository root | 20:20 |
| LarstiQ | RedLizard: right. From my point of view any branch is equal in footing to trunk. | 20:21 |
| RedLizard | LarstiQ: even feature branches, which only exist for a short period of time, only to be merged back into the trunk? | 20:22 |
| LarstiQ | RedLizard: yes. But they're not very likely to exist in a central repository anyway, but live on my machine. | 20:23 |
| RedLizard | LarstiQ: unless you work on a project on multiple machines | 20:23 |
| LarstiQ | RedLizard: but I see some merit in nesting like that. | 20:24 |
| LarstiQ | RedLizard: https://bugs.edge.launchpad.net/bzr/+bug/295704 btw | 20:24 |
| ubottu | Launchpad bug 295704 in bzr "Colocating a branch a repository remotely complains about .bzr not being a local path" [Undecided,New] | 20:24 |
| pygi | hello people | 20:25 |
| LarstiQ | hmm, should be 'and' instead of 'a', a well | 20:25 |
| pygi | me needs some numbers about bzr if possible | 20:25 |
| pygi | anyone awake? :) | 20:27 |
| LarstiQ | pygi: you didn't ask a question yet ;P | 20:27 |
| pygi | truuue :) | 20:27 |
| pygi | basically, number of projects using bzr, and some high-profile names of projects ;) | 20:28 |
| LarstiQ | RedLizard: I still think it's unnatural, but I might be oldfashioned ;) | 20:28 |
| * LarstiQ doesn't know of research into the former | 20:29 | |
| jelmer | pygi, http://bazaar-vcs.org/WhoUsesBzr | 20:29 |
| pygi | jelmer, ok, and how about number of downloads? :) | 20:30 |
| jelmer | pygi, I don't think that's easy to track | 20:30 |
| pygi | jelmer, indeed it isn't | 20:30 |
| jelmer | as most people get bzr from their distribution | 20:30 |
| pygi | jelmer, right | 20:31 |
| pygi | jelmer, just trying to convince some people to do some bzr stuff, and this will help ;) | 20:32 |
| LarstiQ | pygi: who are those people? Are they convinced by 'ubuntu, launchpad, mysql'? | 20:32 |
| pygi | LarstiQ, O'Reilly :) | 20:33 |
| LarstiQ | pygi: aha :) | 20:33 |
| jelmer | pygi, you may want to check ubuntu's popcon | 20:33 |
| pygi | LarstiQ, I think mysql accounts for lot more then ubuntu & LP ;) | 20:34 |
| jelmer | pygi, IIRC that lists bzr as the second most popular DVCS | 20:34 |
| LarstiQ | pygi: depends what they are looking for | 20:34 |
| pygi | LarstiQ, true that too | 20:35 |
| pygi | LarstiQ, I guess adoption rate by external projects | 20:36 |
| LarstiQ | pygi: right | 20:37 |
| pygi | LarstiQ, and we can't really consider LP & ubuntu external :p | 20:37 |
| LarstiQ | pygi: tried the very scientific approach of looking at amount of google hits? | 20:38 |
| * LarstiQ now really is off | 20:41 | |
| pygi | LarstiQ, laters, and thanks | 20:41 |
| pygi | jelmer, thank you too, data sent ;) | 20:45 |
| jelmer | np, hope you can convince them :-) | 20:45 |
| lifeless | Peng_: yeah, its the 'locations defaults override remember values' annoyance; I really must fix that | 20:46 |
| pygi | everyone wants to do a Git book, but bzr one is different stuff... | 20:47 |
| RedLizard | pygi: probably because bazaar is easy enough that you can use it without a book :p | 20:48 |
| pygi | RedLizard, actually, I'm talking from publishers POV ... | 20:49 |
| Pieter | I'd guess it is because there are more git users | 20:50 |
| pygi | Pieter, indeed | 20:50 |
| RedLizard | pygi: I was just kidding. I guess git is popular for one reason: that the linux development team uses (and wrote) it ;) | 20:50 |
| RedLizard | therefore, instant fame | 20:50 |
| jelmer | afaik there was a bzr book on the way | 20:51 |
| Pieter | git didn't become really popular until about a year ago, and it's been in use for the kernel for 2-3 years now | 20:51 |
| jelmer | not sure how far they got though | 20:51 |
| pygi | jelmer, yea, I heard that too ... but nothing new on it since ages ... | 20:51 |
| pygi | I talked about the book with few people here some time ago :) | 20:52 |
| pygi | Pieter, well, it was VERY unfriendly before | 20:53 |
| * jelmer still uses git reluctantly | 20:58 | |
| pygi | jelmer, what project do you use it for? | 21:01 |
| jelmer | samba mainly, but also several other projects I've contributed to (ikiwiki, loudmouth, etckeeper, btslink) | 21:02 |
| pygi | aha | 21:03 |
| jelmer | this is one of the reasons why picking a vcs is so different than picking an editor - it affects not just you, but the rest of the project as well | 21:03 |
| pygi | true | 21:04 |
| Pieter | you can always use git-bzr ;) | 21:14 |
| jelmer | :-) | 21:18 |
| jelmer | Seriously though, I'm not sure how that helps me, it still forces me to use the git UI | 21:18 |
| Pieter | only to push to git, you can use bzr for all the other stuff | 21:20 |
| jelmer | Doesn't gain me an awful lot, it still e.g. requires a local copy of the git repo and a more complex way to upload to the remote git repo | 21:21 |
| jelmer | bzr-git should come close, once I finish implementing remote fetch support | 21:21 |
| Pieter | :) I guess it's more useful the other way around, as git has real branch and remote support | 21:24 |
| jelmer | I would say it the other way around, being the bzr adept that I am :-) | 21:24 |
| jelmer | git requires you to fetch data locally before you can do anything with it, bzr allows you to work directly on remote data | 21:25 |
| jelmer | it would indeed be nice to have git-like branches in bzr, I think that's actually my top-wishlist-item atm | 21:26 |
| pygi | jelmer, wasn't there some work going on getting those? | 21:31 |
| jelmer | not afaik | 21:33 |
| jelmer | it shouldn't be too hard to implement, just nobody hasn't done it yet | 21:33 |
| jelmer | and it would require a format change | 21:33 |
| emmajane | In other news: this is the best use of the internets ever... live web cam of PUPPIES. http://cdn1.ustream.tv/swf/4/viewer.45.swf?cid=317016 | 21:33 |
| * emmajane apologies and encourages you to resume normal activities. :) | 21:34 | |
| jelmer | lol :-) | 21:34 |
| emmajane | :) | 21:34 |
| * jelmer fears he'll just end up looking at puppies all evening, rather than adding new awesome bzr features | 21:36 | |
| emmajane | LOL | 21:36 |
| emmajane | +1 | 21:36 |
| emmajane | jelmer, screen casting has just taken a dramatic back seat to puppy watching. :) | 21:38 |
| Pieter | it has sound too \o/ | 21:39 |
| jelmer | emmajane, :-) | 21:40 |
| emmajane | Pieter, yup :) | 21:40 |
| emmajane | must be supper time? | 21:40 |
| Pieter | that's what they thought | 21:40 |
| jelmer | and there's 8000 more people watching, amazing | 21:40 |
| emmajane | one of them have been assigned box duty... for our viewing pleasure. :) | 21:40 |
| emmajane | back later. :) | 21:42 |
| pygi | jelmer, more format changes :P | 21:46 |
| pygi | jelmer, I don't think people would like that :) | 21:48 |
| jelmer | beer o'clock | 22:21 |
| jelmer | g'night * | 22:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!