Times are UTC Toggle Colours
00:11:28 <Brot6> Backup test: abort: no suitable response from remote hg! 01:08:46 *** KenjiE20 has quit IRC 01:55:49 *** thgergo has quit IRC 02:29:22 <Brot6> 2cc train set - Bug #2180 (New): blablabla from neko (DJNekkid) @ http://dev.openttdcoop.org/issues/2180 03:02:37 *** Lakie has quit IRC 05:33:09 <Brot6> Bundles Update: g1a55d495 2011-01-18 cargodist (http://bundles.openttdcoop.org/cargodist) 07:03:25 <Brot6> NewGRF Meta Language - Bug #2181 (Confirmed): assertion on pkp set (planetmaker) @ http://dev.openttdcoop.org/issues/2181 07:23:52 <Brot6> NewGRF Meta Language - Bug #2181: assertion on pkp set (planetmaker) @ http://dev.openttdcoop.org/issues/2181#change-5386 08:15:29 *** LordAro has joined #openttdcoop.devzone 08:17:30 <Brot6> NewGRF Meta Language - Bug #2181 (Closed): assertion on pkp set (planetmaker) @ http://dev.openttdcoop.org/issues/2181 08:17:30 <Brot6> NewGRF Meta Language - Revision 1136:01958255cf4d: Fix #2181: off-by-one in the output_base:prepa... (yexo) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/01958255cf4d 08:17:30 <Brot6> NewGRF Meta Language - Bug #2181 (Closed): assertion on pkp set (yexo) @ http://dev.openttdcoop.org/issues/2181#change-5387 08:22:24 <planetmaker> nice, Yexo :-) 08:25:18 <Yexo> thanks to you finding the line that triggered the error it was easy :) 09:02:19 <planetmaker> he, that wasn't difficult, either :-) 09:03:07 *** ODM has joined #openttdcoop.devzone 10:01:26 *** Doorslammer has joined #openttdcoop.devzone 10:31:25 *** Doorslammer has quit IRC 11:45:32 *** KenjiE20 has joined #openttdcoop.devzone 12:32:21 *** thgergo has joined #openttdcoop.devzone 12:50:44 <Brot6> 2cc train set - Feature #2182 (New): DR16 (Voyager1) @ http://dev.openttdcoop.org/issues/2182 12:51:09 *** Lakie has joined #openttdcoop.devzone 14:56:56 <Ammler> svn.openttd.org convert to hg: http://hg.openttdcoop.org/svn.openttd.org/ 14:57:01 <Ammler> with tags 14:57:06 <Ammler> and findversion.sh support 14:57:56 <Ammler> always reproduceable without any need of sha1map or whatever 15:28:02 <Brot6> repository /home/hg/all-devzone registered in Redmine with url /home/hg/all-devzone 15:28:02 <Brot6> repository /home/hg/all-devzone created 15:38:41 <dihedral> can i define hooks in hg which are only executed from the server? 15:45:35 <Ammler> yes, we have running such hooks 15:46:11 <Rubidium> ieuw... loads of dead branches 15:46:16 <Ammler> for fetching changesets to redmine or checking messages/files 15:46:33 <Ammler> Rubidium: yes, hgweb does show those 15:46:48 <Ammler> like hg branches -c 15:47:11 <Ammler> but you can quite easy now make clones with default only or whatever 15:53:17 <Ammler> hmm, I wonder, if it pulled extra 15:54:33 <Rubidium> it looks like it 15:54:44 <Rubidium> and... you probably can't compile the masterserver from there 15:54:54 <Rubidium> "there" = your hg clone 15:55:07 <Rubidium> although it's impossible for our hg clone as well 15:55:22 <Ammler> well, that doesn't really matter, does it? 15:55:22 <Rubidium> unless you know what you're doing ofcourse 15:57:16 <Ammler> hmm, findversion needs a patch to support tags for hg repos too 15:57:55 <Ammler> but that could go upstream also if you don't want to use hgsubversion, right? 16:04:37 <Ammler> TAG="$(hg id -t)"; [[ -n "$TAG" ]] && [[ $TAG != "tip" ]] && REV=$TAG || REV="h$(hg id -i)" 16:09:50 <Ammler> http://hg.openttdcoop.org/svn.openttd.org.trunk 16:15:30 <Ammler> also with hgsubversion, you could again make changes in tags :-) 16:28:29 *** frosch123 has joined #openttdcoop.devzone 16:46:29 *** DanMacK has joined #openttdcoop.devzone 16:46:34 <DanMacK> Hey all 16:46:52 <michi_cc> I just uploaded my local git-svn clone to http://www.icosahedron.de/openttd/git/svn_mirror.git for the equivalent to the HG repo. 16:51:04 <Ammler> I patched the hgsubversion to add the svn rev to the commit message 16:51:24 <Ammler> to keep it compatible with findversion, it would indeed not be needed 16:51:49 <Ammler> as there are macros like svnrev(1234) 16:52:45 <Ammler> hg up "svnrev(21825)" would be natively supported 16:53:56 <michi_cc> findversion has code the extract the rev from the native git-svn info, no native command to up to a svn rev though. 16:55:05 <Ammler> how do you update to certain svnrev currently? 16:55:22 <Ammler> also by grepping the logs? 16:56:24 <michi_cc> Actually it has, git svn find-rev rXXX returns the commit hash. That command must be new :) 16:58:44 <michi_cc> So "git checkout `git svn find-rev r10001`" for example 17:00:36 <Ammler> you do also commit from your git? I have no clue, if the hg devs do commit from their hg repos or still with svn 17:01:25 <Ammler> so I can't say, how that works, but it should work :-) 17:01:33 <michi_cc> Yes, I commit with git, but not from the complete clone. I have a plain trunk clone for normal development. 17:02:20 <Ammler> yeah, I would split the hg repo to default and maybe most recent release branch too 17:02:44 <michi_cc> (Which is only because I made that clone much earlier, I certainly could commit from the full repo.) 17:03:07 <Ammler> well, in hg you clone the whole repo per default 17:03:14 <Ammler> I guess, that isn't the case in git? 17:03:51 <michi_cc> It is, it's git-svn which you can tell if you want all tags/branches or just a single branch/trunk. 17:04:19 <Ammler> no, I mean, if you would use that svn-mirror as official git repo 17:04:30 <Ammler> and someone clones that git 17:05:00 <Ammler> afaik, then you clone only master, don't you? 17:05:30 <michi_cc> The clone contains everything, it's just the the master branch is the one that is checked out by default. 17:05:39 <michi_cc> msater == svn trunk in this case 17:05:54 <Ammler> ah ok, thought that is different in git 17:06:22 <Ammler> so git master = hg default = svn trunk 17:07:39 <michi_cc> Yes, but if I would be evil I could also set the master branch on my repo to some obscure svn branch to confuse people :) 17:08:22 <Ammler> well, you could call it trunk :-) 17:11:58 <michi_cc> If a user clones it'll still be called master though, simply because that's the name the first local branch gets by default 17:12:40 <Ammler> hmm, I have no clue, what hg does if there is no branch default 17:13:53 <Ammler> current findversion doesn't support git tags either 17:28:11 <Ammler> michi_cc: http://bugs.openttd.org/task/4428 <-- maybe you like to add git tag support :-) 17:29:07 <michi_cc> Ammler: What about determineversion.vbs ? 17:29:23 <Ammler> oh indeed, I have no clue about that 17:29:50 <Ammler> Yexo: or Terkhen should do that :-P 17:30:40 * Terkhen has no clue about vbs either 17:32:53 <Ammler> he, I thought you develop with msvc 17:34:04 <Terkhen> I only use it sometimes for debugging, usually I use mingw 17:41:16 <Yexo> I do develop with msvc ,but that doesn't mean I magically know that vbs script (or vbs at all) 17:44:22 <Ammler> :-) 17:52:23 <michi_cc> patch for git tags: http://paste.openttdcoop.org/show/54/ (needs the vbs as well) 18:05:41 <michi_cc> Ammler: determineversion.vbs uses different commands for gh than findversion.sh, so I'm not sure how it should look like 18:07:13 <Ammler> michi_cc: and we both missed LANG=C 18:08:06 <michi_cc> No, I didn't :) git name-rev is scripting API that has a stable output 18:10:25 <Ammler> indeed, hg id -t should also be independend 18:10:41 <michi_cc> determineversion.vbs calls "hg parents" where (unmodified) findversion.sh calls "hg id -i". Can hg parents do the tag things as well or should that code actually use hg id? 18:11:06 <Ammler> yes, the tag is also in parent 18:11:36 <Ammler> http://paste.openttdcoop.org/show/55/ 18:11:45 <Ammler> output of hg parent ^ 18:12:32 <Ammler> of course hg id -t is proper way to get current tag 18:12:41 <Ammler> so is hg id -i for the hash 18:13:29 <Ammler> hg parent --template="{svnrev}" <-- svn revision 18:13:48 <Ammler> no sed needed :-) 18:14:22 <Ammler> well, that would need to have hgsubversion clone as official hg repo then 18:15:31 <Ammler> and if so, you need to decide, if you still like to keep svn rev in the commit message 18:15:45 <michi_cc> What's the output of hg id (-t)? 18:15:45 <michi_cc> Does that command also work with the offical hg trunk? 18:16:02 <Ammler> official hg trunk has no tags 18:16:12 <Ammler> so it wouldn't hurt 18:16:32 <Ammler> $TAG is empty or tip 18:16:33 <michi_cc> Yes, but then I don't want to touch the rev number look-up 18:16:42 <Ammler> yeah, I wouldn't either 18:17:18 <Ammler> well, it would make sense to use this for the official hg repos too 18:21:17 <michi_cc> How do I clone your full hg repo? http://hg.openttdcoop.org/svn.openttd.org/ gives me a 502 18:21:17 <Ammler> but tag support and change the mirrors are different tasks 18:24:19 <Ammler> michi_cc: try again, I played around with the hg server :-) 18:26:41 <Ammler> he, it might need some time to clone the whole repo 18:27:43 <michi_cc> Okay, works 18:44:45 <Brot6> AroAI - Revision 11:0f0675288789: Add: Repo commit hook, to make sure that the commit messages ar... (LordAro) @ http://dev.openttdcoop.org/projects/ai-aroai/repository/revisions/0f0675288789 18:48:05 <Ammler> 167M /home/hg/svn.openttd.org 18:48:14 <Ammler> 59M /home/git/openttd-svn-mirror/.git 18:48:21 <Ammler> quite a difference :-) 18:51:54 <michi_cc> Did you really want a git work tree? You can do git clone --bare ... otherwise 18:52:09 <Ammler> yes, that is .git, isn't? 18:52:44 <Ammler> I know --bare, just forgot it 18:52:50 <michi_cc> No, I mean an actual checkout of the source. 18:55:46 <Ammler> yes, I don't need that, that is why I made du for .git 18:56:06 <Ammler> how do I remove the working copy from a clone? 18:59:35 *** LordAro has joined #openttdcoop.devzone 19:01:04 <Brot6> 32bpp-ez-patches: compile of r21834 still failed (#2069) - http://bundles.openttdcoop.org/32bpp-ez-patches/testing/ERROR/r21834 19:03:51 <Brot6> clientpatches: update from r21488 to r21488 done - http://bundles.openttdcoop.org/clientpatches/testing/r21488 19:04:55 <Brot6> serverpatches: compile of r21834 still failed (#2080) - http://bundles.openttdcoop.org/serverpatches/testing/ERROR/r21834 19:14:33 <michi_cc> Ammler: move/rename the .git and change the config file from "bare = false" to "bare = true" 19:21:27 <michi_cc> Ammler: your hg clone has a problem: for example the tag 1.1.0-beta3 is assigned to 243e0e2b9f9a which is r21749 and not r21750 19:22:17 <Ammler> I don't think so 19:23:34 <Ammler> michi_cc: maybe svn detects it wrongly 19:23:54 <michi_cc> Ammler: http://paste.openttdcoop.org/show/56/ 19:23:57 <Ammler> as it uses the rev which does make the tag, not the rev which is tagged 19:24:26 <Ammler> michi_cc: looks fine 19:24:51 <Ammler> r21750 is the rev which made the tag 19:24:58 <michi_cc> The SVN rev of a beta3 svn checkout is 21750 though 19:25:58 <Ammler> I don't think, git can tag something which has no hash yet 19:26:21 <michi_cc> It can, a tag is just a pointer to a commit 19:26:30 <Ammler> yes, exactly 19:26:44 <michi_cc> See http://www.icosahedron.de/openttd/git/svn_mirror.git/commit/3bfbd4c68270e46a0798b1b710c1b9525a591135 19:26:52 <michi_cc> Notice the @21750 19:26:56 *** KenjiE20 has quit IRC 19:27:03 <Ammler> yep, but then git is wrong :-) 19:27:11 <Ammler> or git and svn is not logical 19:27:47 <Ammler> if svn does use the rev of the tagging commit, this would be wrong 19:27:52 <michi_cc> Sorry, it isn't. The commit which created the svn tag was http://vcs.openttd.org/svn/changeset/21750 and not http://vcs.openttd.org/svn/changeset/21749 19:28:06 *** KenjiE20 has joined #openttdcoop.devzone 19:28:10 <Ammler> yep, you don't care about that changeset 19:28:19 <Ammler> you care about the changeset which you tag 19:28:33 <michi_cc> If you check out the svn repo at r21749 you can't checkout the tag though, as it only comes into existance at r21750 19:28:45 <Ammler> e.g. try to tag rev 10000 now 19:29:19 <Ammler> so it is a bug of svn detection 19:29:20 <michi_cc> Nobody said that svn is logical, but findversion.sh reports r21750 for a checkout of http://svn.openttd.org/tags/1.1.0-beta3/ 19:29:27 <Ammler> I wonder, why git does it that way 19:29:38 <Ammler> it is simply wrong 19:31:25 <Ammler> did you configure the git-mirror to make it "wrong"? 19:31:50 <Ammler> where is the changeset, which made that tag? 19:31:51 <michi_cc> It's not wrong, just consistent with SVN. The problem of 1.1.0-beta3 is that the SVN rev only contains a copy but no actual changes. HG seems to drop the "empty" commit and thus places the tag one svn rev too early 19:32:56 <michi_cc> Why do you need a changeset to make a tag? 19:33:04 <Ammler> michi_cc: well, I meant svn does make it wrong, not your git mirror script :-) 19:33:32 <Ammler> not svn, the findversion for svn 19:33:56 <Ammler> michi_cc: you don't need to commit taggin? 19:34:25 <michi_cc> Of course not, placing tags in-tree like hg isn't a very good idea IMHO 19:35:27 <Ammler> so how do you sync a tag with remote? 19:36:26 <Ammler> well, I need to ask the hgsubversion guys, if it is possible to make it as wrong as git 19:36:54 <Ammler> but it would be better, if you fix that with findversion, imo 19:37:22 <michi_cc> Either git fetch --tags / git pull --tags or with explicitly specifying which tags 19:38:09 <Ammler> can't svn tag a revision which is say 1000 revs behind? 19:38:13 <michi_cc> Don't forget that 1.1.0-beta3 is an exception as it doesn't have real changes, older tags do have changes and aren't dropped by hgsubversion 19:38:50 <Ammler> e.g. it is not possible to tag r10000 anymore? 19:38:51 <michi_cc> http://www.icosahedron.de/openttd/git/svn_mirror.git/commit/d0676de44b19d7903bd482140b10d1bdaca89e1b i.e. 1.1.0-beta1 is NOT empty 19:39:10 <michi_cc> It can, but the tag revision will still be the current rev 19:39:34 <Ammler> which would be obvious wrong, but hg would make that irght 19:39:56 <michi_cc> And as long as most tags in the openttd svn repo do contain real changes, you can't just let hg/git point to the previous revision 19:40:03 <Ammler> I think, also svn would make that right, just findversion fails 19:40:06 <Ammler> and maybe git 19:40:36 <Ammler> michi_cc: hgsubversion has support for changes in tags 19:40:45 <Ammler> that is why I tried it at all 19:41:03 <Ammler> it simply makes branches with the tags too 19:41:13 <Ammler> (unamed branches) 19:41:15 <michi_cc> It has, and 1.1.0-beta1 has the right svn version, it's just the "empty" tag commits that don't match 19:45:05 <michi_cc> Aynway, http://paste.openttdcoop.org/show/57/ is what I would make out of it for determineversion.vbs 19:55:14 <michi_cc> There's another catch with your findversion.sh patch: It reports 1.0.0-1.0 for 1.0.0 because 1.0.0 is also on the 1.0 branch, while svn will only report either the branch or the tag. Clearing $BRANCH when a tag is found would solve that. 19:55:48 *** KenjiE20 has quit IRC 19:56:53 *** KenjiE20 has joined #openttdcoop.devzone 20:15:49 <Ammler> does it really matter, if findversion shows +-1 rev, I feel quite unconforable to change that to a unlogical thing 20:16:19 <Ammler> but I guess, it is also quite hard for svn to fix that 20:16:49 <Ammler> so can't we just leave that as it is :-) 20:17:50 <Rubidium> Ammler: nah, it's not that bad. The only caveat of mismatching svn revisions is that you can't join or be joined 20:17:59 <Ammler> as you don't use the svn rev of releases anyway for newgrf version detections 20:18:19 <Ammler> Rubidium: since when does it use the svn rev for releases? 20:18:37 <Rubidium> beta1-ish? 20:18:54 <Ammler> really, well, then you should make it right :-P 20:19:14 <Rubidium> I should make what right? 20:19:43 <Ammler> findversion.sh does show the rev of the destination instead the source 20:19:50 <Ammler> or how someone calls that in svn 20:20:51 <Rubidium> destination? source? 20:21:11 <Ammler> it uses the svn revision of the tagging, instead of what the tag points to 20:21:38 <Rubidium> a tag is nothing more than a branch in svn 20:21:51 <Rubidium> not some fancy metadata that points to some revision 20:22:15 <Rubidium> as such the version of a tag, is the revision it got committed in. It's not the revision it got branched from 20:22:36 <Ammler> yes, which is unlogical 20:22:49 <Rubidium> why? 20:23:07 <Ammler> ah, I just said, what would happen, if you tag r10000? 20:23:18 <Ammler> what would findversion show 20:23:34 <Rubidium> if I would tag it now? r21836 20:23:50 <Ammler> and you think, that is right/logical? 20:23:55 <Rubidium> as I'd be *branching* it 20:24:30 <Rubidium> whether it is logical with the concepts of hg/git is besides the point 20:24:45 <Ammler> nah, nothing to do with hg/git 20:24:53 <Rubidium> subversion is built on a completely different concept 20:25:20 <Rubidium> "trunk" is a directory, "branches" is a directory, "tags" is a directory 20:25:27 <Ammler> I have a newgrf which requires r150000, and you make a release of r10000 now 20:25:30 <Rubidium> so you basically have one big versioned directory structure 20:26:14 <Ammler> r15000* 20:26:35 <Rubidium> Ammler: *if* I were to do that, then... 20:26:44 <Rubidium> * r10000 would be a stable branch 20:26:58 <Rubidium> * r15000 would be trunk or a later stable branch 20:27:44 <Rubidium> * we pass major/minor/build to NewGRFs, which get bumped on branches 20:28:18 <Rubidium> 0.5.0.1512345 < 0.6.0.12345 20:29:08 <Rubidium> ergo, there's no problem 20:30:11 <Ammler> well, lets see 20:30:39 <Rubidium> what I would find odd is that, at r12000 r10000 has no tag, whereas at r15000 r10000 magically gets a tag and as a result gets compiled totally different 20:31:06 <Rubidium> that could actually cause problems with OpenTTD's network protocol 20:35:34 <michi_cc> Ammler: http://www.icosahedron.de/openttd/patches/hg_tags.patch is what I have right now. Seems to work but who knows what I might have missed. 20:37:08 <Ammler> michi_cc: I can test only the findversion part, but it looks good 20:37:46 <Ammler> I just compile a beta3, wondering, if I can join .stable 20:40:37 <Ammler> Rubidium: I can join .stable just fine 20:41:44 <Ammler> ottdc@games:~/svn-stable> ./findversion.sh 20:41:45 <Ammler> 1.1.0-beta3 21750 2 1.1.0-beta3 20:41:56 <Ammler> marcel@inspiron:~/hg/svn.openttd.org> ./findversion.sh 20:41:57 <Ammler> 1.1.0-beta3 21749 2 1.1.0-beta3 20:42:22 <Ammler> so it doesn't look like it uses the rev_nr 20:42:33 <Ammler> am I missing something? 20:42:55 <Rubidium> oh... *cough* *cough* it's only doing revision checks for stable releases 20:43:13 <Rubidium> for the rest the name check is enough 20:43:26 <Rubidium> although... you can get desyncs if the revisions mismatch 20:44:38 <Ammler> well, you mean for future releases? 20:44:48 <Ammler> so there is still time to revert that :-) 20:47:34 <Rubidium> I won't revert that revision check for stable releases 20:47:50 <Ammler> or is it really time to start making openttd uncompatible to dvcs? 20:48:05 <Rubidium> no 20:48:27 <Rubidium> it *has* been really time to make OpenTTD uncompatible with so-called "releases" that aren't real releases 20:48:44 <Rubidium> i.e. thank zodttd for the need of this check 20:49:37 <Ammler> well, but I am sure, you could make it a way, it would still be compatible to a clean hg/git convert 20:51:07 <Rubidium> what does you script return for 1.1.0-beta1? 20:52:25 <Ammler> http://hg.openttdcoop.org/svn.openttd.org/rev/1.1.0-beta1 -> r21615 20:52:39 <michi_cc> It is compatible with a clean git-svn convert. 20:53:31 <Rubidium> Ammler: so when we *do* make changes in the tag it's getting the right version number 20:53:39 <Ammler> ah, I thought, it just worked with the "empty" tag 20:54:26 <Rubidium> given the stable release will have changes in the tag everything should be right 20:57:51 <Ammler> he, this funny, but now I see 20:58:25 <michi_cc> Ammler: Is it okay if I commit the hg patch or do you want to change anything? 20:58:36 <Ammler> I just wonder, how git is able to distinguish that 20:58:53 <Ammler> michi_cc: the findversion part looks fine 20:59:09 <Ammler> other lines have LANG=C, but I don't think it is needed there 20:59:12 <Ammler> for hg id 20:59:32 <planetmaker> better use it 21:00:12 <michi_cc> There's nothing translatable in the output 21:00:18 <Ammler> planetmaker: it make sense for hg parent 21:00:44 <Ammler> but hg id is really just the id, which needs to be equal in every languagen 21:00:57 <planetmaker> michi_cc: got the link to the hg patch? 21:01:06 <Ammler> http://www.icosahedron.de/openttd/patches/hg_tags.patch 21:01:14 <planetmaker> ah, ty 21:01:25 <Ammler> (was still in my clipboard :-) 21:02:08 <planetmaker> reads easy enough 21:02:24 <Ammler> hmm, hgsubversion has "stupid" mode 21:02:55 <Ammler> maybe that would tag the "wrong" rev 21:03:11 <Ammler> I will ask that tomorrow 21:08:57 <Ammler> btw. is using [[ EXPRESSION ]] instead [ EXPRESSION ] bashism? 21:09:06 <Ammler> since bash recommends 2 21:10:09 <Rubidium> are there [[ ]] expressions in configure/config.lib? 21:10:41 <Ammler> not, but I made those and removed it again as I saw the rest doesn't have 2 21:10:58 <Rubidium> then it's likely a bashism 21:11:08 <Ammler> ok :-) 21:11:40 <Rubidium> though checkbashisms could check that 21:11:52 <Rubidium> or you could run it under a non-bash shell compatible shell 21:12:47 <Ammler> suse doesn't know that 21:34:00 <Brot6> GRFCodec - Revision 820:df3f039f15ef: Add: action0 railtypes properties 17..19 (Rubidium) @ http://dev.openttdcoop.org/projects/grfcodec/repository/revisions/df3f039f15ef 21:37:19 <SmatZ> I think "[ EXPRESSION ]" calls program "[" (linked to "test"), while "[[" is bashism 21:38:03 *** LordAro|2 has joined #openttdcoop.devzone 21:38:45 *** andythenorth has joined #openttdcoop.devzone 21:38:55 <andythenorth> evenings 21:39:55 *** LordAro|3 has joined #openttdcoop.devzone 21:42:23 *** LordAro has quit IRC 21:42:24 *** LordAro|3 has quit IRC 21:42:45 *** LordAro|3 has joined #openttdcoop.devzone 21:42:49 <DanMacK> Hey Andy, how goes it? 21:43:28 <andythenorth> evenings DanMacK 21:43:36 * andythenorth has been to the big London 21:44:47 <DanMacK> Exciting :D 21:46:23 *** LordAro|2 has quit IRC 21:54:43 *** frosch123 has quit IRC 21:55:10 * DanMacK likes greeble :D 21:58:57 *** LordAro|3 has quit IRC 22:06:26 <andythenorth> bed time 22:06:28 <andythenorth> good night 22:06:30 *** andythenorth has left #openttdcoop.devzone 22:28:21 <planetmaker> hm. announcement is slooooow. 22:29:16 <planetmaker> 12 minutes lag on NML 22:30:02 <planetmaker> anyway... good night 22:30:39 <Ammler> planetmaker: either slow or not working 22:31:00 <Ammler> check if redmine fetched it 22:31:55 <Ammler> if is slow, if announces at .44, which means the hook didn't work -> please report 22:32:30 <Ammler> the usual speed is max delay 100sec 22:33:24 <Ammler> I don't see any nml annoucement at all 22:34:38 <Ammler> planetmaker: btw. how do you commit to the openttd svn? 22:40:29 <dihedral> svn commit -m 'message' ? :-P 22:43:29 <Ammler> dihedral: not everyone does it that way :-) 22:43:48 <Ammler> maybe planetmaker does hg push... 22:44:09 <dihedral> eh.... 22:44:15 <dihedral> no 22:44:34 <Ammler> how you know? :-P 22:44:34 <dihedral> even if you clone the svn to hg, it's not really a good idea to start messing with the clone 22:44:53 <dihedral> you continue using svn for commits 22:44:56 <Brot6> NewGRF Meta Language - Revision 1137:90017c0725e9: Add: Railtype properties 0x17 ... 0x19 (introd... (planetmaker) @ http://dev.openttdcoop.org/projects/nml/repository/revisions/90017c0725e9 22:45:08 <dihedral> you can however run both in one 22:45:24 <dihedral> i.e. i have an svn working copy and do hg init, and hg add in there 22:45:29 <Ammler> dihedral: michi__cc does commit with git 22:45:40 <dihedral> then i can hg revert to any revision, and commit using svn 22:45:50 <Ammler> hgsubversion does support pushing to svn 22:46:01 <Ammler> I was wondering, if someone already does it that way 22:46:09 <dihedral> uh :-P 22:46:15 <dihedral> sounds risky if you ask me 22:46:35 <Ammler> well, it does commit the changeset, strips it and pulls again 22:48:59 <dihedral> perhaps i am a bit too sensitive regarding production environments :-P 22:50:02 <Ammler> well, the svn admin does not notify, if the client is svn, git or hg or whatever, how should it 22:51:21 <Ammler> I can't test hgsubversion on our svn server, it doesn't have any write access anymore :-) 22:52:35 <dihedral> create an svn repo locally? :-) 22:52:41 <dihedral> access it with file:/// 22:53:18 <Ammler> mäh, is that that easy? 22:53:33 <Ammler> I thought, svn is hell complicated to setup :-) 22:54:06 <Rubidium> svnadmin create $path 22:54:08 <dihedral> nah :-) 22:54:14 <dihedral> it's very simple 22:54:31 <Rubidium> svnserver -d -r $path 22:54:49 <dihedral> i used to have svn repos locally for a few projects 2 years ago 22:55:36 <Ammler> then the complicated part is to publish svn repos? 22:56:48 <dihedral> they can be accessed via svn+ssh 22:57:05 <dihedral> which is basically giving out ssh access 22:57:15 <dihedral> or svnserve which is not that difficult either 22:57:23 <Ammler> ok 22:57:27 <dihedral> and then there is via apache :-) 22:57:47 <dihedral> (and nginx in the mean time i think, not 100% certain though about that) 22:59:18 <Ammler> isn't it possible with dav? 22:59:20 <Ammler> webdav 22:59:28 <Ammler> which nginx is able to do 23:00:06 <Ammler> I use that to have a central sync place for firefox 23:00:33 <dihedral> yes, but it's not a plain webdav i think 23:01:26 <Ammler> oh, no svnserver installed :-o 23:03:35 <Ammler> ah svnserver isn't needed for local usage 23:08:38 <dihedral> nope :-) 23:13:08 <Ammler> I wonder, if I shall setup a svn server and sync our svn or if shall simply convert to hg what we still need 23:28:04 *** DanMacK has quit IRC 23:29:21 *** ODM has quit IRC 23:44:39 <Brot6> Polish PKP Set - Revision 5:925ba8fa52f5: Feature: Snpss, first beta release (BarthVader) @ http://dev.openttdcoop.org/projects/pkp-trainset/repository/revisions/925ba8fa52f5