Latest Git snapshot raises "Range Check error"

[aehimself]

Done. If everything works as expected, the Github repository will be updated daily at 0:30 now by a Jenkins job. We also could have it check the Zeos svn every xxx minutes and have it run then.

Awesome job as ever, thank you very much!

This all is still considered to be experimental. If things go wrong I might have to delete the GIT repository and start over new.

It's easier than you think. That's the good thing in git. You srew up something bad, you just reinitialize the repository. I'll just re-fork it afterwards and all is set.

[aehimself]

Hello aehimself,
i've resolved your rangecheck regression see:https://sourceforge.net/p/zeoslib/code-0/6486/

Other devs like to take it easy when it comes to bug reports, but no, not you, guys. You are blazing fast. Seriously, hats off.

puh your git was very very old, propably ... time for svn?

lol - some would say it is time for Zeos to move to git

I'm not against anything, but the source of larger community-driven projects (at least which I met and use) are stored by Git on different sources. My first real version control (not counting v1-0-0-0.zip, v1-0-0-1.zip, etc ) was Git though so we can say I am biased

Done. If everything works as expected, the Github repository will be updated daily at 0:30 now by a Jenkins job.

If this solution works, I will be more than satisfied. I did not know that Jan refreshed the repository manually, and it was already perfect; at least for me. Do my changes in my repository, cherry pick back to 7.3-testing and issue a pull request. I don't know how much work it is to "accept one" (as it seems to be manually merged to SVN and then synced out to Git again) but it would make me sleep better knowing that it's convenient as well for YOU.
So yeah, count my vote. If you are open to blackmailing, I'll buy you a beer each if you switch

[marsupilami]

Other devs like to take it easy when it comes to bug reports, but no, not you, guys. You are blazing fast. Seriously, hats off.

Thank you. We do our best. But it really depends on the rest of our lifes. Also you tend to give quite precise error descriptions. That helps a lot

I'm not against anything, but the source of larger community-driven projects (at least which I met and use) are stored by Git on different sources. My first real version control (not counting v1-0-0-0.zip, v1-0-0-1.zip, etc ) was Git though so we can say I am biased

Hmmm - that is because Git was made by Linus Torvalds and got a lot of attention this way Git has a lot of strengths. Its biggest strength is giving more freedom to every developer who works on a project, so I can totally understand why it is so popular. And I have to admit: We stick to subversion because we already know how to use it. If I had to find two things about subversion that I like better than with git it would be the following:

• Subversion has a linear history. Revisions are numbered and they are ordered. Revision 4 is newer than revision 3. That doesn't work as easy on git and its hashes. I do admit that this probably is a false sense of control.
• Another thing is that git allows no partial checkouts - which commonly leads to the recommendation to have one repository for one project only. This is a great idea if you know exactly what the project is. Unfortunately I usually don't. I start to develop things inside one project and then decide to move them. On SVN this isn't so much of a problem. I can decide to redesign my SVN tree and do partial checkouts for the subprojects. If the subprojects heavily depend on each other they still can share the same history. I am not sure how to do that on git.
• Even though I said it was only two things, here is a third thing: Subversion uses a simpler approach to version control than git. This makes it more easy to understand for developers that don't want to think about version control at all. The following is a true story: I work together with my mother. She didn't understand why to use version control at all - at least at first. She all did it file based and by hand. It was a big fight to get her to just use "svn commit" and maybe "svn update" on a graphical tool (TortoiseSVN). I can only assume that getting her to use git would have been a bigger fight - just because there would have been more steps to do and the scheme behind it would have been more complex. Git has a lot of advantages. But like most tools these advantages have the cost of making it more complex and by this more complex to understand.

Regarding "the source of larger community-driven projects [...] are stored by Git": Before the adoption of git most of these projects used subversion (and CVS before subversion): The tool that I use for updating git was developed by the KDE people. They used it to migrate their subversion into git.

I don't know how much work it is to "accept one" (as it seems to be manually merged to SVN and then synced out to Git again) but it would make me sleep better knowing that it's convenient as well for YOU.

Currently it works like this:

1. See that a merge request is incoming in my inbox
2. Download the patch file for that merge request
3. Apply the patch to the SVN by using the apply pach command of tortoise svn
4. Commit it to SVN
5. copy the SVN commit to git or wait for the automatic commit.
6. Turn down the merge request - which is the hardest part because it doesn't show your work on github. On github it still looks like I did the work.

So yeah, count my vote. If you are open to blackmailing, I'll buy you a beer each if you switch

Honestly - you have to convince Egonhugeist. He is doing the most commits. If he decides, he wants to change, I will happily do the conversion. Most probably we wouldn't use github though but still stay with Sourceforge because we have the bugs and everything else there too.

[Fr0sT]

I'm a gitter as well (had to learn SVN only for Zeos) so might be a bit subjective.

* Linear history - Git has it too though no Rev numbers, only hashes instead.
* Partial checkouts - you can extract any commits as patches and apply them in another repo, or use Git submodules

[marsupilami]

I'm a gitter as well (had to learn SVN only for Zeos) so might be a bit subjective.

We all are

* Linear history - Git has it too though no Rev numbers, only hashes instead.

Yep - learned that today by testing - git will enforce a linear history when pushing or committing...

* Partial checkouts - you can extract any commits as patches and apply them in another repo, or use Git submodules

Hmm - extracting a lot of patches and recommitting them sounds like a lot of work And git submodules - they are a poor replacement for a partial checkouts. Assume something like this: Somebody wants to write documentation on Zeos and only needs the documentation subdirectory. If we want to support him in checking out only that part, we would have to move the documentation into a separate submodule?
Anyway - I think partial checkouts are no use case for Zeos. Almost all work requires the checkout of a complete branch. So the missing parital checkouts are no reason for not moving to git.

Since I am no gitter - I still wonder if git-svn is of any use for git users. Opinions?

Best regards,

Jan

[aehimself]

Dear god, what have I done

[Fr0sT]

Hmm - extracting a lot of patches and recommitting them sounds like a lot of work And git submodules - they are a poor replacement for a partial checkouts. Assume something like this: Somebody wants to write documentation on Zeos and only needs the documentation subdirectory. If we want to support him in checking out only that part, we would have to move the documentation into a separate submodule?
Anyway - I think partial checkouts are no use case for Zeos. Almost all work requires the checkout of a complete branch. So the missing parital checkouts are no reason for not moving to git.

I'm afraid I lost your point somewhere as I'm not quite clear on what "partial checkouts" really mean. Git has no path-based access control, that is true. But it's not hard to extract a more or less standalone part to separate repo, give some rights to some dudes and plug it into main repo as submodule. With one post-commit hook it could be automatically sync-ed to main one. Or, if talking about GitHub, there's setting to forbid commits to master branch without approval of project owners.