Irrlicht source (and git)

[hendu]

Huh?

include/SVertexIndex.h: ASCII C++ program text

^ that file is LF (unix). One of the many.

I haven't tried to compile trunk as-is in months, nowadays when I do I first do a recursive dos2unix -U to get something sane.

[hybrid]

Not for me, not in SVN/trunk. I've found exactly 3 files (include/E*) which didn't have the eol property set and were using unix style. Also found that MSVC only fixes eol style if a file has mixed cases, otherwise it seems to handle this properly and even kkeps the eol style. But all three files are now also fixed. Still I don't think that a wrongly set eol style is an argument for or against a SCM system.

[hendu]

Not for me, not in SVN/trunk.

I think that's because you have the mentioned SVN magic on. It's obviously something not on by default, since I have the same result with a fresh checkout just to test things.

Running:

$ svn proplist -v include/SVertexIndex.h
Properties on 'include/SVertexIndex.h':
svn:eol-style
CRLF

However, the file itself is clearly LF.

Still I don't think that a wrongly set eol style is an argument for or against a SCM system.

I haven't said it is? I only said it makes it harder for both you and contributors.

[CuteAlien]

Getting the file as LF is pretty confusing - this would bascially be a svn bug. The documentation on this rather clear - the eol-style which is set defines the way you get files when checking out. There isn't much else we can do there (we could use another eol-stlye like native, but that doesn't seem to be the problem here). It's also correct at least on my main system, I just checked once more just to be sure.

[hendu]

I agree, that seems likely given that nobody else has said anything similar.

At least this would be a point against svn then Keeping count:
- number of git bugs I have hit so far: 0
- number of svn bugs hit so far: 1

[ACE247]

What SVN bug? I have a plain normal Linux Console SVN client and every project thats programmed properly compiles without a single complaint, including irrlicht svn trunk. So really I think you are some sort of bug artists or you're just using plain weird svn clients...

[hendu]

I'm going to ignore the "worksforme"

$ svn --version
svn, version 1.7.1 (r1186859)

[anylo]

What happened yesterday:

I'm reading forum and notice that someone had issues with the same demo that I once tried. Problem was that demo was outdated against the WIP version of the library.

"Well, I can fix that."

Here is a list what I did

• I forked library in bitbucket (= pressed fork button)
• Cloned it locally (hg clone ...) from bitbucket
• Made the changes and committed those to my local fork
• Cloned local fork to local test, tested the changes
• Pushed my fork back to bitbucket
• Made pull request (= pressed Pull request button) so if the author of the library likes what I did he can add that to library
• Posted link to my fork to forum so others can also get the updated demo

Svn just don't support community very well...

[hybrid]

Yeah, pretty useful for the user who wants to create its very own version from an arbitrary number of distributed versions across the internet. But it's the common case that counts here. And that's the main repository, with only a few maintainers working on it. Now the distributed approach means that we few developers have to keep track of every repository created somewhere, assess the changes and their quality online, and make sure that theo whole repository keeps online until we get to a point to include this code. Instead, right now everyone is asked to provide the patches, which we can work on off-line and focused on the few changes that were made in this step.
So it's basically not what is possible with distributed SCMs, but what is necessary to keep all the stuff maintained. Right now, if someone does not provide a patch, the changes are likely to be not accepted by the community anyway. It's too much work to get those things joined into an own repository. With hg or git, this whole preparation is casted onto the core team, hoping that as many people from the community will stay with the proposed maintenance scheme.
BTW: with SVN I'd get a clean copy form the repository, make changes, test, create a patch, upload the patch to the central bug tracker. No need to get any other url for whatever reason, every user can easily apply this to the own repository...

[anylo]

Yeah, pretty useful for the user who wants to create its very own version from an arbitrary number of distributed versions across the internet. But it's the common case that counts here. And that's the main repository, with only a few maintainers working on it. Now the distributed approach means that we few developers have to keep track of every repository created somewhere, assess the changes and their quality online, and make sure that theo whole repository keeps online until we get to a point to include this code.

Based on the number of the factual errors in your comment I see that you do not understand the concept.

[hybrid]

Well, I do know the concept and I work with git repositories in other projects. But I also have the view of a project maintainer, who might have different requirements. And unfortunately we do not have the ability to use our full-time job for Irrlicht development. So we need a simple and quick solution. It's not that we are the Linux kernel dev team, where a huge hierarchy of maintainers and repositories are used to maintain and merge huge quantities of code. In our situation, we would be faced with a few dozen distributed branches, which are not necessarily well documented, adhering to any kind of coding guideline or project architecture or are used for more than just one patch at all. If you know about projects of this size and style that are successfully using the distributed approach just tell us. Would be interesting to see how it works. But for now I'd trade bleeding edge patch access for general maintainability, staying with SVN.
Oh, and in case you want to say just put the branches into your local repository, in case availability is an issue: That's the same, I'd have to keep track of all those changes in my local branches somehow. Once I work on a patch I will probably approach the original author anyway instead of working through the changes all on my own.

[hendu]

I want to add the recent situation that happened to me. SVN does not allow for contributors to make incremental patches, so using SVN here makes for a lose-lose situation.

a) User combines them: more work for her, harder to review for you.
b) User posts them separately: more work for her, merge conflicts for you.
c) User does not bother, no patch for you.