Log for #openttdcoop.devzone on 18th January 2011:
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) @
03:02:37  *** Lakie has quit IRC
05:33:09  <Brot6> Bundles Update: g1a55d495 2011-01-18 cargodist   (
07:03:25  <Brot6> NewGRF Meta Language - Bug #2181 (Confirmed): assertion on pkp set (planetmaker) @
07:23:52  <Brot6> NewGRF Meta Language - Bug #2181: assertion on pkp set (planetmaker) @
08:15:29  *** LordAro has joined #openttdcoop.devzone
08:17:30  <Brot6> NewGRF Meta Language - Bug #2181 (Closed): assertion on pkp set (planetmaker) @
08:17:30  <Brot6> NewGRF Meta Language - Revision 1136:01958255cf4d: Fix #2181: off-by-one in the output_base:prepa... (yexo) @
08:17:30  <Brot6> NewGRF Meta Language - Bug #2181 (Closed): assertion on pkp set (yexo) @
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) @
12:51:09  *** Lakie has joined #openttdcoop.devzone
14:56:56  <Ammler> convert to hg:
14:57:01  <Ammler> with tags
14:57:06  <Ammler> and 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>
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 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: <-- 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: (needs the vbs as well)
18:05:41  <michi_cc> Ammler: determineversion.vbs uses different commands for gh than, 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) 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>
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? 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) @
18:48:05  <Ammler> 167M    /home/hg/
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) -
19:03:51  <Brot6> clientpatches: update from r21488 to r21488 done -
19:04:55  <Brot6> serverpatches: compile of r21834 still failed (#2080) -
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:
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
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 and not
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 reports r21750 for a checkout of
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> 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, is what I would make out of it for determineversion.vbs
19:55:14  <michi_cc> There's another catch with your 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> 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> <
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: 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> ./
20:41:45  <Ammler> 1.1.0-beta3     21750   2       1.1.0-beta3
20:41:56  <Ammler> marcel@inspiron:~/hg/> ./
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> -> 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>
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) @
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) @
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) @

Powered by YARRSTE version: svn-trunk