| igc | poolie: ok. I actually think it's pretty straight forward to add deep history support to usertest so I'll do that today after kicking off a conversion | 00:00 |
|---|---|---|
| lifeless | poolie: I think its interesting to have deep linear too; because many conversions will be like that | 00:00 |
| poolie | sure | 00:01 |
| lifeless | and in the short term, most huge histories will be conversions | 00:01 |
| foom | yes, my repo came from svn, so it's essentially linear | 00:01 |
| poolie | i guess for ease of understanding the results we need to pick one main case to graph | 00:10 |
| lifeless | I would say rather that we should be repeating on the same graph | 00:11 |
| lifeless | we might have N big graphs to test, all different | 00:11 |
| poolie | testing N could be good, i'm just a bit concerned that if we produce too much output data it will not be read | 00:11 |
| lifeless | well whats the audience | 00:12 |
| lifeless | will the audience read 1, or N, or none ? | 00:12 |
| lifeless | right now I don't look at usertest daily | 00:14 |
| lifeless | I only look at such things when I'm a) deciding what to put in my pipe, and b) evaluating how I'm doing with my current changes | 00:15 |
| lifeless | if you have someone who is trying to do a) on any of a number of scales, N graphs is little harder to read that 1, and better at detect regressions caused while operating on code for the case of b) | 00:16 |
| lifeless | I'll wager that you have a similar use pattern | 00:16 |
| lifeless | but that Ian, who is focusing on a) in a broad sense, daily, looks at it quite frequently. | 00:17 |
| lifeless | http://www.smh.com.au/articles/2008/02/05/1202090393959.html <- hmm | 00:28 |
| poolie | i'm fixing a merge conflict to merge, and jam has a todo asking for the trace file to be line buffered so you can more easily read it | 00:29 |
| poolie | should i do a trivial change to have a debug option to turn that on, or yagni? | 00:29 |
| lifeless | the trace file is buffered right now right? | 00:30 |
| lifeless | for performance | 00:30 |
| poolie | yes | 00:30 |
| poolie | up to several kb, whatever is the python default | 00:30 |
| lifeless | I've had no trouble tailing it | 00:30 |
| lifeless | but if we change it yes, it should be a flag | 00:31 |
| poolie | oh, actually the comment is wrong, it is always line buffered | 00:32 |
| poolie | which is fine | 00:32 |
| poolie | thanks Teddy! :) | 00:32 |
| lifeless | lol | 00:32 |
| mattimustang | hi, i'm looking at converting from svn to bzr. Does bzr support svn style properties? | 00:35 |
| lifeless | mattimustang: I answered your question before; did you not see the answers ? | 00:35 |
| mattimustang | sorry i missed it and lost it in scollback :( | 00:35 |
| mattimustang | so it doesn't support arbitrary properties like svn? | 00:36 |
| lifeless | 10:39 < lifeless> some yes | 00:36 |
| lifeless | 10:40 < lifeless> is this for 3rd party extension, or for file-ending support on windows etc? | 00:36 |
| lifeless | 10:40 < lifeless> (that is are you asking about 'generic stuff' or specific features) | 00:36 |
| lifeless | 10:41 < foom> it doesn't support keywords or eol-style | 00:36 |
| lifeless | 10:41 < lifeless> foom: yet; I have a plan. | 00:36 |
| mattimustang | thx | 00:36 |
| mattimustang | I have custom properties aside from what svn uses (keywords eol-style etc) | 00:37 |
| lifeless | per file or per commit ? | 00:37 |
| mattimustang | per file | 00:37 |
| mattimustang | file metadata like unix permissions, owner, group | 00:37 |
| lifeless | ok | 00:38 |
| lifeless | well I'm designing a plugin to store those precise attributes | 00:38 |
| lifeless | with a lookaside structure from the core | 00:38 |
| * jelmer wakes up | 00:39 | |
| lifeless | we have arbitrary revision properties, and you can do things like e.g. storing a dict of the changed file properties you want in a revision property - so {fileid:newvalue, ...} | 00:39 |
| lifeless | this isn't entirely ideal, but making arbitrary properties DTRT all the time is rather tricky, when you have to consider performance-at-alarge | 00:40 |
| mattimustang | i really need the metadata to stay with the file it belongs to | 00:40 |
| lifeless | yes, what I describe does that | 00:40 |
| lifeless | files have uuid | 00:40 |
| mattimustang | if files move I don't want to have to update some other manifest elsewhere | 00:40 |
| lifeless | a rename does not change the uuid (which we call file_id) | 00:40 |
| jelmer | lifeless: wouldn't it make more sense to store it in a . file in the root of the tree? | 00:42 |
| lifeless | jelmer: that makes it a user file | 00:43 |
| jelmer | I wouldn't want to check out a 30000-revision branch with several thousand files that each have a couple of properties set | 00:43 |
| lifeless | jelmer: remember the trouble with altering the representation of .bzrignore | 00:43 |
| foom | so store it in a \0 file in the root of the tree? :) | 00:43 |
| lifeless | a) we reject that filename, b) its the same problem | 00:44 |
| jelmer | lifeless: .bzr/repository/fileprops.knit would be ok as well | 00:44 |
| lifeless | jelmer: a knit? wtf | 00:45 |
| jelmer | that's also how i'd like to see .bzrignore support | 00:45 |
| jelmer | ed | 00:45 |
| jelmer | well, a knit or a pack or whatever | 00:45 |
| jelmer | it can be in the pack file as well, depending on your repository type | 00:45 |
| lifeless | jelmer: in the broad sense you are saying 'this should be in the core' | 00:45 |
| jelmer | lifeless: Yes, I am. | 00:45 |
| lifeless | jelmer: and thats fine, I want to get something up and working as a plugin, then when its stable, design an appropriate extension to core to do it well. | 00:46 |
| jelmer | lifeless: ah, ok. I hadn't seen you say that anywhere yet. That makes sense though. | 00:46 |
| lifeless | as a plugin the goal is to work and be decoupled from repository format | 00:46 |
| lifeless | figure out all the data needed, how it changes, what it needs. then design good storage. | 00:47 |
| lifeless | so I'm thinking it will be slowish as a plugin, but easy to tweak | 00:47 |
| jelmer | I would really like to avoid a "bzr setprop" kind of UI for setting these things btw | 00:48 |
| lifeless | oh I cannot tolerate that ui | 00:48 |
| lifeless | never happen | 00:48 |
| jelmer | ok :-) | 00:49 |
| lifeless | I mean, see my comments re the shell hook stuff | 00:49 |
| mattimustang | what would propose then? | 00:49 |
| jelmer | lifeless: I think being able to write python should not be a requirement for being able to write bzr hooks. | 00:50 |
| lifeless | mattimustang: well I made a suggestion, or do you mean about how to activate this feature for a branch ? | 00:50 |
| lifeless | jelmer: I think our hooks and hg/svn hooks are different beasts. | 00:51 |
| jelmer | lifeless: For commonly used hooks, those should definitely be in python. | 00:51 |
| lifeless | jelmer: our hooks are gateways into the core library; like svn's baton passing. | 00:51 |
| mattimustang | well my original question was does bzr support it and it seems that it doesn't | 00:51 |
| lifeless | the stuff you want should be done by specific adapters | 00:51 |
| jelmer | s/commonly/installable/ | 00:51 |
| lifeless | mattimustang: it has arbitrary properties that can be set per commit; you can build out what you want easily there | 00:51 |
| mattimustang | how would you do that per file then? | 00:52 |
| jelmer | lifeless: For example, we check whether a commit message contains a specific line here at a svn repository | 00:52 |
| lifeless | mattimustang: I already described it; you seem to think it wouldn't work. | 00:52 |
| jelmer | lifeless: most people know shell and can write a two-line shell script that checks a commit message is valid. | 00:53 |
| lifeless | jelmer: thats fine; do an adapter like I posted to the list for running make check. Then most users can write such a two line shell script | 00:53 |
| lifeless | jelmer: this is entirely different from trying to write a FFI to shell for our hooks. | 00:53 |
| mattimustang | so that is still using svn main repo for checkins and hook script. ok that is fine i can understand that approach but what about going purely bzr? | 00:54 |
| lifeless | mattimustang: huh? what I described was using bzr | 00:54 |
| foom | my 2 line shell script for doing that exact function is actually a 116 line python script. :) | 00:54 |
| jelmer | lifeless: Which thread was this? I don't think I've seen that. | 00:54 |
| foom | 43 lines of which are a function called "get_cmd_output" which I use to call "svnlook log" and "svnlook changed", since the server doesn't have python 2.4 (and thus the subprocess module), and popen.* are terrible | 00:56 |
| jelmer | you mention posting a pre-commit-check hook in the "Enhancing hooks" thread, but I can't find it | 00:56 |
| lifeless | jelmer: 1202182868.659.144 | 00:56 |
| lifeless | Config.get_user_section api | 00:56 |
| mattimustang | "(11:39:13 AM) lifeless: we have arbitrary revision properties, and you can do things like e.g. storing a dict of the changed file properties you want in a revision property - so {fileid:newvalue, ...}" is that what you are talking about? | 00:57 |
| lifeless | mattimustang: yes | 00:57 |
| mattimustang | ok | 00:57 |
| jelmer | lifeless: I don't see how that is all that different from my shell hooks plugin | 00:58 |
| jam | poolie: I did intend to have bzr-log-rss as part of the bzr project. I just wanted to allow someone else to have access aswell. I did the same thing for bzr-pqm-devel since James didn't want to be in ~bzr | 00:58 |
| poolie | got it | 00:58 |
| lifeless | jelmer: I didn't claim it was. | 00:59 |
| lifeless | jelmer: Ian posted work to create a generic FFI for our python hooks. | 00:59 |
| lifeless | jelmer: I think that that is a bad idea. | 00:59 |
| jelmer | lifeless: ahhh, ok. I see your point. | 01:00 |
| lifeless | in short - some hooks that work well available for shell - great. | 01:01 |
| lifeless | all hooks in shell - are you insane? | 01:01 |
| jamesh | you think multiple fork+exec's for common operations would be a performance problem? | 01:03 |
| * fullermd is insane. | 01:03 | |
| lifeless | jamesh: we'll only pay that when someone has chosen to use a shell hook | 01:03 |
| jelmer | lifeless: right, and there's not always an obvious conversion between python types and shell types.. | 01:03 |
| lifeless | jamesh: so no, because we can and should also make it really easy to write absolutely trivial python hooks - by providing base class hook implementations that do most of the grunt work | 01:04 |
| jamesh | lifeless: one thing that would be nice would be to centralise the hook registration APIs | 01:04 |
| jamesh | lifeless: rather than doing some on SmartTCPServer.hooks, some on Branch.hooks, etc | 01:04 |
| jelmer | jamesh: even when done centrally, those hooks would still only apply to some objects | 01:04 |
| lifeless | jamesh: like the two like 'check a regex in the commit message' should be in python, about 8 lines - import regex, import a currier that takes a plugin name and looks for config stuff with that prepended, and then a simple 'get regex, execute it, return' | 01:05 |
| jamesh | jelmer: I realise that. | 01:05 |
| lifeless | jamesh: I don't actually like a single global registry; what is better about it ? | 01:05 |
| jamesh | lifeless: well, the current system kind of works against lazy_import | 01:06 |
| jamesh | lifeless: if I want my plugin to hook the SmartTCPServer, then every invocation of bzr is going to import bzrlib.smart.server once my plugin is installed | 01:07 |
| lifeless | OTOH we wouldn't need lazy_import if python imports didn't suck so much | 01:07 |
| lifeless | so I have on my todo list to fix that for bzr | 01:07 |
| lifeless | and a pretty good idea about how | 01:07 |
| lifeless | what else? | 01:08 |
| foom | there's already packages which implement lazy module importing | 01:08 |
| jamesh | lifeless: I guess that's my main complaint. A central hooks registry was a solution to that, but you've obviously thought of some alternatives that might be better | 01:08 |
| yacc | pkg_resources entry points? | 01:09 |
| jamesh | lifeless: actually, the other one is discoverability of hooks | 01:09 |
| lifeless | jamesh: I'd like bzr help plugins/hooks to dump them all | 01:10 |
| jamesh | okay | 01:10 |
| lifeless | jamesh: I think thats thats nicer because it allows plugins to add hooks themselves too | 01:10 |
| lifeless | (not that a central place prohibits that, but because it doesn't lend it self to it quite as nicely if you think about it this way) | 01:11 |
| jamesh | at the moment you have to dig through the code to find out where to register your hook, what the name of the hook is, and what arguments it should expect | 01:11 |
| lifeless | yes, that sucks | 01:11 |
| lifeless | also debug.debug_flags has the same problem | 01:11 |
| === jam_ is now known as jam | ||
| * igc food | 02:39 | |
| === mw is now known as mw|out | ||
| * spiv -> late lunch | 04:04 | |
| abentley | Can I not join ~bzr-log-rss-devel please? I get enough spam from Launchpad as is. | 04:13 |
| abentley | by spam, I mean bugs on bzr-eclipse, bugs on bzr-webserve, branchfeed, etc. | 04:15 |
| abentley | These are not projects I have ever been interested in. | 04:15 |
| Aloha | when i "man bzr" i get this weird output http://www.pastebin.ca/893506 | 04:35 |
| beuno | Aloha, that's wierd, me too | 04:35 |
| beuno | but if I have my terminal maximized, it doesn't happe | 04:36 |
| beuno | *happen | 04:36 |
| beuno | Aloha, you should report the bug to the Ubuntu package (might also happen in Debian, dato?) | 04:37 |
| Aloha | ok | 04:38 |
| beuno | Aloha, that would be https://bugs.launchpad.net/ubuntu/+source/bzr/ | 04:38 |
| Aloha | beuno, thnx | 04:38 |
| beuno | I'm going to bed now, I swear :D g'night all | 04:39 |
| beuno | Aloha, thanks for filing it! | 04:39 |
| mtaylor | abentley: I've got a question about the bundlebuggy workflow... that's the pqm, right? so once a merge is approved there, it gets merged to the tree? | 04:39 |
| abentley | mtaylor: No, they are separate systems. | 04:39 |
| mtaylor | ok. so what happens once a merge is approved on bb? | 04:40 |
| abentley | mtaylor: A person with clearance submits it to PQM. | 04:40 |
| mtaylor | abentley: so there's still a manual step there then | 04:41 |
| abentley | mtaylor: Indeed, and frequently more. | 04:41 |
| abentley | Because many patches need to have conflicts fixed before they can merge cleanly. | 04:41 |
| mtaylor | ah | 04:41 |
| mtaylor | ok | 04:41 |
| mtaylor | and then the PQM system is the one that runs the unit tests before pushing to the tree, no? | 04:42 |
| Aloha | bug filed | 04:42 |
| abentley | Yes. Technically it merges, runs unit tests, then commits. | 04:42 |
| mtaylor | cool. makes sense | 04:42 |
| abentley | The conflict issue has gotten a lot better since we started doing NEWS alphabetically, though. | 04:43 |
| abentley | So submit-from-bb isn't completely out of the question. | 04:44 |
| mtaylor | I tell you what, changelogs and news files really screw with merges in general :) | 04:44 |
| abentley | mtaylor: Someone should write a merge algorithm for NEWS and CHANGELOG files. | 04:44 |
| mtaylor | you could almost have bb submit and then ask for a re-submit if the merge didn't work. | 04:44 |
| mtaylor | abentley: I totally agree. I'd be in favor of that! | 04:44 |
| mtaylor | abentley: my debian/changelog files are always a problem | 04:45 |
| abentley | mtaylor: Great. Let me know when you have something >;) | 04:45 |
| mtaylor | :) | 04:45 |
| mtaylor | so bzr-pqm is just the submit-to-pqm plugin though, right? Is pqm itself released? | 04:45 |
| abentley | Yes it's an open project. | 04:45 |
| abentley | http://people.ubuntu.com/~robertc/pqm/ | 04:48 |
| mtaylor | abentley: awesome. thanks | 04:48 |
| bob2 | is there any support for plugging file-type-specific merge algorithms into bzr? | 04:49 |
| === asac_ is now known as asac | ||
| abentley | bob2: No, but you can write your type-specific merge so that it falls back to merge3. | 04:50 |
| abentley | General merge algorithms are pluggable. | 04:50 |
| bob2 | ah | 04:51 |
| bob2 | neat | 04:51 |
| mtaylor | abentley: so what if bob2 wrote a file-type merge algorithm, and I wrote a debian/changelog algorithm, and I had both file types in my tree? | 04:52 |
| abentley | mtaylor: Obviously, it doesn't scale. | 04:52 |
| mtaylor | :) | 04:52 |
| abentley | I did some work on per-file merge algorithms, but I didn't nearly finish it. | 04:53 |
| mtaylor | I'd say I'd think about it further, but I'm like 12 deep on my stack of non-essential work at the moment anyway | 04:53 |
| spiv | poolie: a fix for bug 185394 is on the list, if you'd like to review it | 06:07 |
| ubotu | Launchpad bug 185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Critical,Fix committed] https://launchpad.net/bugs/185394 | 06:07 |
| fullermd | Oooh. Purdy. | 06:09 |
| poolie | thanks spiv | 06:32 |
| === jam_ is now known as jam | ||
| mazzanet | herro | 10:20 |
| mazzanet | how do you get a diff of the local tree and the repository that includes any new files added locally? | 10:21 |
| mtaylor | mazzanet: have you commited those files ? | 10:22 |
| mazzanet | i don't have commit access to the repository | 10:23 |
| mazzanet | ie. i'm making a patch | 10:23 |
| fullermd | diff should do it just fine in general (though it won't for binary files). | 10:24 |
| bob2 | "bzr diff" will show the difference between your current checkout and the main thing | 10:24 |
| fullermd | The usual answer, though, is jut to commit in a local branch. Then you can send a merge directive and keep all your metadata. | 10:24 |
| bob2 | but this new-fangled distributed thing means you can create your own branch ;) | 10:25 |
| mazzanet | bzr diff isn't including the new files | 10:25 |
| fullermd | Did you 'bzr add' them? | 10:25 |
| bob2 | (bzr add will work even if you can't commit) | 10:25 |
| mazzanet | really? | 10:25 |
| mazzanet | crazyness | 10:25 |
| mazzanet | cheers | 10:27 |
| mazzanet | *dances* | 10:27 |
| jblack | bob2??? | 10:29 |
| jblack | Bob2!!! | 10:30 |
| fullermd | jblack: Oh, hey there. Didn't see you come in. | 10:31 |
| jblack | I came in on tippy-toes. ;) | 10:31 |
| jblack | cprov too! wow | 11:35 |
| cprov | jblack: hi James. Good to see you again. | 11:36 |
| * jblack gets amazed by the people he sees when he crawls out from under his rock | 11:36 | |
| jamesh | hi jblack | 11:36 |
| jblack | Hey jamesh | 11:36 |
| jamesh | jblack: and bob2 still has the hair ... | 11:38 |
| jamesh | and denies that he plays goon of fortune | 11:38 |
| jblack | Heh. | 11:38 |
| === mrevell is now known as mrevell-lunch | ||
| === doko_ is now known as doko | ||
| abentley | jblack: Hi. | 12:47 |
| jblack | Hi | 12:50 |
| CardinalFang | Aloha. | 12:51 |
| abentley | What colour rock have you been hiding under? | 12:51 |
| jblack | A black one, of course | 12:52 |
| jblack | it sounded funnier in my head. | 12:52 |
| abentley | Heh. | 12:52 |
| kiko | heh | 13:00 |
| kiko | hey jblack how's it going? | 13:01 |
| === mrevell-lunch is now known as mrevell | ||
| jblack | hi | 13:29 |
| jblack | Pretty good. | 13:29 |
| ubotu | New bug: #189567 in bzr "output to a terminal should default to using /usr/bin/pager" [Undecided,New] https://launchpad.net/bugs/189567 | 13:31 |
| === zmanuel is now known as z-man | ||
| === mw|out is now known as mw | ||
| === _emgent is now known as emgent | ||
| === brilliantnu1 is now known as brilliantnut | ||
| === kiko is now known as kiko-fud | ||
| === weltende is now known as welterde | ||
| === statik` is now known as statik | ||
| synic | anyone awake? | 15:12 |
| synic | how can I get bzr to mark files with the current revision number? | 15:12 |
| Parker- | hmmhh... like $rev$ or something? | 15:13 |
| synic | yeah | 15:14 |
| jam | synic: short answer, no | 15:14 |
| jam | longer answer... http://bazaar-vcs.org/KeywordExpansion | 15:14 |
| jam | you might look at "bzr version-info" | 15:14 |
| synic | k | 15:14 |
| Parker- | heh | 15:14 |
| jam | But it is more about putting it into another file | 15:14 |
| jam | ATM we don't change files for you on commit | 15:14 |
| synic | alright | 15:15 |
| Parker- | hmmhh... in future... is it possible to lock files? | 15:15 |
| Parker- | if branch is checkouted | 15:16 |
| Parker- | (or binded) | 15:19 |
| Spads | So I once had infinity rattle off a zillion commands at me explaining how to do this, but short term memory's always the first to go... | 15:36 |
| Spads | I've got a tree where I maintain an internal patch to upstream sources. new tarballs appear periodically, and I want to just incorporate that stuff and keep my set of changes on top. | 15:37 |
| Spads | infinity said there was a "maintaining a patch" section in the docs, but I can't find it | 15:37 |
| Spads | he mumbled about doing lots of imports from tarballs, but that seems to blat the whole tree out with the upstream files. | 15:37 |
| Spads | HI! I always swap "infinity" and lifeless in my head | 15:39 |
| Spads | hi lifeless | 15:39 |
| Spads | they're both so eternal | 15:39 |
| jam | Spads: there is http://bazaar-vcs.org/TrackingUpstream | 15:40 |
| jam | And I know there is "bzr import" provided by bzrtools | 15:41 |
| jam | Generally, I would say you want to have a pristine branch of upstream | 15:41 |
| jam | which your work is derived from in another branch | 15:41 |
| jam | and then you go to upstream | 15:41 |
| jam | update to the latest tarball | 15:41 |
| jam | commit | 15:41 |
| jam | then go to your branch | 15:41 |
| jam | merge in the changes | 15:41 |
| jam | commit | 15:42 |
| jam | go on with your life | 15:42 |
| jam | http://jameswestby.net/tips/tips/hacking-a-project-with-bzr.html | 15:42 |
| jam | also describes that workflow | 15:42 |
| jam | only with "upstream" being in svn | 15:42 |
| Spads | okay, this is close to what we were doing already. I may have misheard him as it sounded like he was talking about everything in-place | 15:42 |
| jam | Spads: he has a plugin to do that | 15:42 |
| jam | but I don't think it is fully released yet | 15:43 |
| Spads | ahaaaa | 15:43 |
| jam | Last I read was that it needed a bit of polish, and should be released within the next month or so | 15:43 |
| === kiko-fud is now known as kiko | ||
| muszek | hi... I have a local branch binded with a branch on a remote server. I'm using bzr+ssh URI. When commiting, I'd like the remote working directory to be updated at the same time... is it possible? Right now I have to issue commit locally, wait till it's finished and issue "bzr update" command on the remote server (I want to skip that 2nd part) | 16:19 |
| jelmer | muszek: you can use the push-and-update plugin for that | 16:22 |
| muszek | jelmer: thanks | 16:25 |
| muszek | can I specify the path that I want to run bzr commant at? something like "ls -A /var/www" shows me stuff in a specified directory (not the one I'm currently at). Say I'd like to run something like "bzr update /var/www/myapp" | 16:48 |
| jelmer | bzr update /var/www/myapp should work | 16:50 |
| pygi | muszek, yes, you can ;) | 16:50 |
| muszek | damn... It does work... I must have messed up something before. thanks and sorry guys. | 16:51 |
| Wonko | Hi guys, I have a noob Q: I have a project on two machines that has a settings file that differs for these machines. Everything else is the same and needs to be kept in sync. | 16:51 |
| pygi | muszek, no worries ;) | 16:51 |
| pygi | Wonko, you can ignore that settings file | 16:51 |
| pygi | Wonko, bzr ignore [file] | 16:52 |
| Wonko | But the settings file might change in the non-specific parts , is there a better way maybe? | 16:52 |
| Wonko | thought about ignoring, but it seemed unelegant ;) | 16:52 |
| pygi | Wonko, perhaps you might want to split settings file to two separate files? One common, and one specific? | 16:53 |
| pygi | Wonko, and just ignore the common one? :) | 16:53 |
| Wonko | @pygi: that sounds like a good idea. Mercurial has something called "Mercurial Queues" that allow me to "plug in" patches, which would sound ideal for my case. Does bzr have something like that? | 16:54 |
| Wonko | ( Hg stuff: -> http://hgbook.red-bean.com/hgbookch12.html#x16-26700012 ) | 16:55 |
| pygi | Wonko, gimme a moment to read it pls | 16:55 |
| Wonko | I'm still thinking about where to move to from CVS, bzr or Hg (or maybe darcs) .. | 16:55 |
| Wonko | sure, take your time, and THANKS! | 16:55 |
| pygi | Wonko, per-se, I don't think bzr has something similar, however I believe a plugin like that could be written | 16:59 |
| Wonko | k, thanks so far! | 17:00 |
| pygi | Wonko, thank you, and dont hesitate to ask if you have more questions :) | 17:01 |
| foom | i wish there was a way to have both, at once. | 17:01 |
| foom | a revision history of the changes i actually made, *and* a sensible split into patches of the same changes | 17:02 |
| pygi | foom, that approach doesnt scale .... i.e. see darcs :) | 17:02 |
| foom | pygi: ...just because darcs doesn't scale doesn't mean what i want is impossible. :) | 17:02 |
| pygi | true that foom :P | 17:03 |
| pygi | foom, you could write a bzr plugin that does that, anyway | 17:03 |
| foom | no i couldn't | 17:03 |
| foom | maybe someone could | 17:03 |
| pygi | hehe :) | 17:03 |
| foom | but i don't even have a precise enough idea of what I want it to do to start. | 17:04 |
| batoms | is there a quick fix for a corrupted dirstate? | 17:08 |
| batoms | mine appears to be corrupt and i can't do anything on my tree | 17:08 |
| luks | a quick fix would be "bzr branch <broken> <fixed>" | 17:10 |
| luks | but filing a bug report about that is probably a good idea, too | 17:10 |
| pygi | and we'd appreciate it :) | 17:10 |
| batoms | branching doesn't work | 17:12 |
| batoms | #186014 | 17:12 |
| batoms | Bug #186014 | 17:12 |
| ubotu | Launchpad bug 186014 in bzr "MemoryError on diff/commit" [Undecided,New] https://launchpad.net/bugs/186014 | 17:12 |
| luks | branch fails with the same error as e.g. diff? | 17:13 |
| batoms | pretty much everything fails | 17:14 |
| batoms | except for bzr info | 17:14 |
| batoms | and bzr log | 17:14 |
| luks | umm, I'm pretty sure branch used to work | 17:14 |
| batoms | the last comment on that bug give the traceback | 17:14 |
| batoms | for branch | 17:15 |
| luks | hmm | 17:16 |
| luks | rm -r broken/.bzr/checkout && bzr branch broken fixed | 17:16 |
| luks | but obviously backup the broken one before | 17:17 |
| batoms | but then i lose track of the my recent uncommitted changes on the tree | 17:19 |
| abentley | batoms: after that, you can move the .bzr/checkout from the new tree into the old one. | 17:20 |
| batoms | that did the trick, thanks | 17:21 |
| luks | maybe there should some hidden command to regenerate the dirstate from scratch | 17:21 |
| foom | jelmer: so i ran bzr svn-push, and it's been running for about 20 minutes so far, and I have no idea what it's doing or if it's going to work; is there any way to have it print some debugging info about what it's doing? | 17:22 |
| jelmer | foom: If you run it with -Dcommit, it should write debug info to .bzr.log | 17:22 |
| jelmer | sorry, ~/.bzr.log | 17:22 |
| abentley | luks: The reason why branch breaks here now is that branch uses the local tree if it can to accelerate the process. | 17:22 |
| abentley | luks: Perhaps we could hang it off 'reconcile'. | 17:23 |
| muszek | anyone knows some good article with arugments for using version control systems? | 17:59 |
| abentley | luks, foom: push should work fine with a broken dirstate, so we didn't have to delete .bzr/checkout (though we would have had to replace it). | 18:11 |
| Parker- | hmmhh... trying to get bzr-svn work... and windows stuff is not aynmore located in http://home.comcast.net/~klight/bzr/ | 18:24 |
| === abadger1999 is now known as abadger_afk | ||
| orospakr | What is the proper way to migrate from git to bzr? The git plugin throws a scary traceback when I try to branch a local git repo. Tailor adds a gross SHA1 hash to the beginning of the commit messages. | 19:11 |
| orospakr | ah, bzr-git has a separate branch with pull support. | 19:12 |
| orospakr | marked "VERY EXPERIMENTAL", though... | 19:12 |
| luks | should be fine for one-time conversion, I guess | 19:13 |
| luks | (that is, not incrementally sync the git branch) | 19:13 |
| luislavena | hello everybody | 19:15 |
| luislavena | anyone knows why the smart server reports format unnamed when asked for info? | 19:15 |
| luislavena | bzr info . (pack-0.92) | 19:16 |
| luislavena | bzr info bzr://localhost => format: unnamed | 19:16 |
| orospakr | luks, yikes, it won't even load. | 19:35 |
| orospakr | AttributeError: 'GitRepository' object has no attribute 'base' | 19:35 |
| beuno | luislavena, you must have a pre 1.0 version of bzr, probably 0.9 | 19:36 |
| beuno | (on the smart server) | 19:36 |
| beuno | s/0.9/0.90 | 19:36 |
| luislavena | beuno: nop, both 1.1 | 19:36 |
| luislavena | anyway, i'm running on the same machine :P | 19:37 |
| luislavena | oh, btw, windows... :D | 19:37 |
| beuno | luislavena, does "bzr version" output the same in both? | 19:37 |
| beuno | luislavena, oh, and you probably have to provide a full path to the smart server | 19:38 |
| luislavena | beuno: mmm, I chdir to the path I want to share... and all the other information it returns seems ok... | 19:40 |
| luislavena | (shared repository, branch info, even the push location) | 19:40 |
| luislavena | beuno: nop, still the same, even with --directory pointing the same location. | 19:43 |
| luislavena | weird, but it works. | 19:43 |
| mtaylor | http://rafb.net/p/0k9wig17.html | 20:06 |
| mtaylor | um... wtf? | 20:06 |
| mtaylor | so, he did a bzr merge from a merge directive... then did a bzr revert, then a bzr pull, then a bzr commit | 20:07 |
| mtaylor | and this is the resulting change | 20:07 |
| mwhudson | mtaylor: looks like the pull only brought in revision data, not text data | 20:11 |
| === kiko is now known as kiko-afk | ||
| === Gwaihir_ is now known as Gwaihir | ||
| ubotu | New bug: #189709 in bzr "added-but-not-commited files which are removed go into weird limbo" [Undecided,New] https://launchpad.net/bugs/189709 | 20:45 |
| === jam_ is now known as jam | ||
| johnny | hi, anybody familiar with the cvsps-import tool? | 21:15 |
| johnny | i'm not sure if i have enough to make it happen, or i'm missing something | 21:15 |
| johnny | my cvs fu is weak after years of not using it | 21:15 |
| lifeless | johnny: sure what problem are you having though ? | 21:36 |
| johnny | exactly how much access to the cvs tree do i need? | 21:36 |
| johnny | since it doesn't seem to support :ext: or :pserver: | 21:36 |
| lifeless | AIUI a copy of it | 21:37 |
| lifeless | it needs to extract the ,v files | 21:37 |
| lifeless | because you are converting history | 21:37 |
| fullermd | I think you can use the non-local protocols if you --use-cvs or something. | 21:37 |
| johnny | so, not just a checkout ? | 21:37 |
| fullermd | Probably a lot slower, though. | 21:38 |
| lifeless | johnny: you can try --use-cvs as fullermd says | 21:39 |
| lifeless | and no, it does not operate off of a checkout, it operates off of the repo | 21:39 |
| === mw is now known as mw|food | ||
| johnny | syntax ? | 21:40 |
| lifeless | I've always used it on local paths | 21:43 |
| johnny | well, i am working with a codecoop repository | 21:44 |
| johnny | a sf clone kinda thing | 21:44 |
| johnny | the nightly does seem to have a CVSROOT dir in it | 21:44 |
| fullermd | Doesn't, you mean? | 21:45 |
| johnny | it does | 21:45 |
| lifeless | untar that backup somewhhere then :) | 21:45 |
| johnny | yeah.. lemme try again | 21:45 |
| fullermd | Oh. Yeah, working off that would be a lot quicker than trying to do it remote :) | 21:45 |
| johnny | i had problems with it | 21:45 |
| johnny | we're only talking less than 1000 revs, so either way.. no big deal | 21:45 |
| johnny | no complicated branching | 21:45 |
| johnny | etc | 21:45 |
| johnny | time is not an issue | 21:46 |
| johnny | here's what i have | 21:48 |
| johnny | ohnny@beep ~/projects/redemmas $ ls infoshopkeeper-scm-2008-02-06/ | 21:48 |
| johnny | CVS CVSROOT infoshopkeeper | 21:48 |
| johnny | i musta got the command sequence wrong before when trying this | 21:49 |
| johnny | so this should be enough? | 21:49 |
| johnny | ohnny@beep ~/projects/redemmas $ bzr cvsps-import infoshopkeeper-scm-2008-02-06/ infoshopkeeper isk | 21:49 |
| elmo | is there anyway to diff without a working tree? | 21:50 |
| lifeless | elmo: upgrade your bzr ;) | 21:51 |
| johnny | lifeless, is that good? | 21:51 |
| lifeless | johnny: that looks right to me | 21:51 |
| elmo | lifeless: >> 1.0 ? | 21:51 |
| lifeless | elmo: 1.1 I think - unless your 1.0 supports --old and --new | 21:51 |
| elmo | lifeless: mmk | 21:51 |
| mwhudson | it needs > 1.0 | 21:52 |
| johnny | http://rafb.net/p/yCqF6A35.txt | 21:52 |
| johnny | that's what i see | 21:52 |
| lifeless | whats in CVSROOT ? | 21:57 |
| johnny | CVS dir and a bunch of scripts it seems : commitinfo,checkoutlist,config,cvswrappers,loginfo,modules,rcsinfo , etc | 21:58 |
| lifeless | ok its legit | 21:58 |
| lifeless | whats in infoshopkeeper ? | 21:58 |
| johnny | CVS, and the normal files | 21:59 |
| lifeless | ,v ? | 22:00 |
| johnny | ? | 22:00 |
| lifeless | say you have NEWS | 22:00 |
| lifeless | is it NEWS | 22:00 |
| lifeless | or NEWS,v ? | 22:00 |
| johnny | aha.. just NEWS | 22:00 |
| lifeless | so ,v is what CVS puts after its database files | 22:01 |
| johnny | so it's not the full thing then | 22:01 |
| lifeless | the CVSROOT files - commitinfo etc should also have commitinfo,v for the history of them | 22:01 |
| lifeless | indeed it does not look like your history | 22:01 |
| lifeless | there should be some sort of backup tarball you can get | 22:01 |
| johnny | suprised it even included the CVSROOT then | 22:01 |
| johnny | i wonder if i can bug them for the whole thing | 22:01 |
| johnny | it'd prolly be easier to just do it remotely tho | 22:02 |
| lifeless | jam: ^ can you advise ? | 22:02 |
| === mw|food is now known as mw | ||
| ubotu | New bug: #189757 in bzr "Interrupted initial push leads to branch reference" [Critical,New] https://launchpad.net/bugs/189757 | 22:46 |
| jam | lifeless, johnny: It certainly sounds like you are just getting a checkout, and not the actual repository | 22:50 |
| jam | It is *close* to supporting :pserver: I just never took the time to actually do it | 22:51 |
| jam | as most people who are converting have access to their source | 22:51 |
| jam | and it is faster that way anyway | 22:51 |
| johnny | well, i guess i could email the codecoop people for the source | 22:52 |
| johnny | but.. then how can i later sync branches | 22:52 |
| lifeless | bah | 22:58 |
| lifeless | soft failures for the lose: | 22:59 |
| lifeless | Unable to test plugin "launchpad": cannot import name test_lp_registration | 22:59 |
| jam | johnny: well, you just ask them for another code drop :) | 22:59 |
| lifeless | our test suite is passing on pqm but the lp plugin tests are not running. | 22:59 |
| igc | morning | 22:59 |
| jam | johnny: though if you want ongoing conversions, Launchpad does a pretty good job of it | 22:59 |
| lifeless | jam: ^ an example of why I don't like the dynamic test stuff you want to do :( | 22:59 |
| johnny | i'd prefer not to rely on launchpad | 23:00 |
| johnny | i'd like xmpp notices of commits , and other such things | 23:00 |
| johnny | and i'd have to wait on them to provide it | 23:01 |
| johnny | the whole point of this operation is to get a package that is relatively bigger than any of the other code stuff that we have | 23:01 |
| jam | lifeless: you just make them hard-failures if you have something which looks like "test_*" and doesn't actually load | 23:02 |
| johnny | so i can test out bzr on it | 23:02 |
| johnny | to see if it will work for us | 23:02 |
| jam | johnny: well if that is all you want, the bzr source code is certainly available | 23:02 |
| jam | if you only have 1k commits, bzr is a lot bigger than that | 23:02 |
| johnny | i mean with one of our own projects | 23:02 |
| johnny | to test working with it in real life, with real commits :) | 23:02 |
| jam | johnny: true, all of the bzr commits are faked :) | 23:03 |
| jam | anyway, I understand your point | 23:03 |
| jam | as for testing converting and then converting future work | 23:03 |
| jam | it should just amount to getting another copy of the ,v files, and running it again | 23:03 |
| jam | as long as you keep the conversion directory around | 23:03 |
| johnny | i'll be happy when pserver happens | 23:04 |
| johnny | then i can just pull into it | 23:04 |
| lifeless | jam: IMO anything we try to load must load or the tests must fail. | 23:04 |
| johnny | ok, i'm going to to get admin access to the project until pserver works | 23:07 |
| jam | johnny: i don't expect to have time to work on ;pserver: for quite a while, but it shouldn't be hard if you want to play with it | 23:08 |
| jam | And I'm happy to give answer questions | 23:08 |
| johnny | i'm still learning python | 23:08 |
| johnny | i don't work in a software job except php web devel | 23:08 |
| johnny | but our coffeehouse has about 5 projects we want to manage | 23:09 |
| johnny | yes.. a coffeehouse with folks who write code for it :) | 23:09 |
| johnny | bookstore/coffeehouse really.. | 23:09 |
| lifeless | sounds cool | 23:09 |
| ubotu | New bug: #189771 in bzr "launchpad plugin tests broken" [Critical,New] https://launchpad.net/bugs/189771 | 23:31 |
| abentley | lifeless: Any luck with the index stuff? | 23:42 |
| lifeless | abentley: in progress | 23:49 |
| poolie | i'm going to read spiv's network patch now | 23:49 |
| lifeless | don't byte off more ... groan sorry | 23:49 |
| === jam_ is now known as jam | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!