Revision control systems

[3400tZ]

I'm surprised the code for this project isn't on GitHub. SourceForge is a bit primitive and kind of outdated. I could talk about SVN vs GIT as well but I don't want to start any war. But one thing for sure, being on github and bringing the social coding aspect into the loop can only help getting people involved by creating forks of the project and eventually pull requests.

Just a thought

[AndreyB]

SVN vs GIT

You are totally right with your arguments, Git is for sure more advanced. I just do not see this as a serious step up - what is important for me right now is that SVN is just a bit simpler. I have too much stuff going on so I'd rather merge .patch files then preach to people how to work with GIT.

Another thing - and I might be wrong with that - but for now I need the source code to be more centralized. I hope it is not much harder for contributors, but it sure thing is much easier for me this way.

[kb1gtt]

I find git nearly non-usable. I spend more time being lectured about how to do it properly which can almost never be done via an easy to use GUI, it almost always has to be done via command line. I find I spend more time checking things into the repo, than creating actual content that needs a repo. I also find that when I use tools like TortorisGIT, it's easy to git a broken repo. There really needs to be a better tool for incompetent folks like myself. I shouldn't dance for the computer, it should dance for me. I've been tempted to play with Mercurial, but haven't gotten around to it. Is Mercurial a user friendly option and does it have a friendly GUI? Github could get some social attention, but other than that are there any features that would make a significant difference? I find PDMworks for Solidworks to work well, even mechanical engineers and managers can use it.

Also anyone can check out the SVN, then check in their own copy into the github. After all git's goal is that you have all sorts of personal distributed repo's, not one shared repo. SVN allows you to take ownership of files, git does not, that's because SVN is a multi-user repo.

I know folks often have a strong preference about repo, perhaps this should be moved to a repo thread. I know both russian and I have been frustrated with revision hell, but meh, it works, and I've found the work flow issues with SVN are better than the work flow issues with git.

[puff]

KISS?

[kb1gtt]

KISS is that next generation of GIT that's usable by the average person

[puff]

… ultimately meaning SVN

[3400tZ]

SVN vs GIT

You are totally right with your arguments, Git is for sure more advanced. I just do not see this as a serious step up - what is important for me right now is that SVN is just a bit simpler. I have too much stuff going on so I'd rather merge .patch files then preach to people how to work with GIT.

Another thing - and I might be wrong with that - but for now I need the source code to be more centralized. I hope it is not much harder for contributors, but it sure thing is much easier for me this way.

I can definitely understand wanting to keep thing simple. I was the first to say GIT was way too complicated over SVN. Once you start playing with it tho, you realize its not that bad at all. Also you can always use GIT like you use SVN. The only extra step you will have to do is a "git push" after a "git commit". Once you start to get more familiar with it, you can start using the other features as needed.

As for centralized, you will still have your repo and you will still commit to that only. The fact that people can create forks can decentralize the code in a sense but you can always (and probably should ?) ignore the forks and wait for a pull request. Someone can work on a feature on their own repo and when ready, pull request the change to you. To me, it's seems like using SVN and sourceforge is actually more complicated for social coding then say using git and GitHub. The github flow is also a very nice way of organizing working with multiple people on the same code base.

Again, not trying to start any war, just stating my opinion and experience with switching over to GIT with a pretty big team that SVN just wouldn't work.

[AndreyB]

Gimme a bug team and I switch to GIT tomorrow

[kb1gtt]

I've used github before https://github.com/jharvey there are some bits up there that folks might find handy or interesting. I've found it to be blah, for those of us that aren't 100% software. I agree it's great for development of large software projects were many people are involved and such. However I feel it's not the optimal tool for many situation.

I also wonder why it's common place for people that suggest using GIT, to also consider themselves to be entering into a potential war zone. You're not the first or last to take this approach. I tend to feel that's a cultural issue. Ultimately I hope we find a tool that does the key features we need, then we use it because it does something of significant importance. If not then debating about it is nothing more than just shed color.

If we are to move to GIT, probably the best way to do it, is for someone to check the repo into git, and then share the work via github. Then the other developers would be forced to consider GIT. For now I think we're best off battling with revision hell, as we have a working system and we keep making incremental progress. However if someone wants to make some progress and drag us along for a ride, I'm sure the current developers would adapt.

[AndreyB]

https://sourceforge.net/ is down more and more often, I have no choice but to try https://github.com/rusefi/rusefi at least as a backup. github has a subversion interface so I will start wit that.

[kb1gtt]

Ah, that's to bad, now you won't have multiple people complaining that this should be on GitHub. That's a loss in free advertisement

Fingers crossed that it works out.

[jedediah_frey]

I I also find that when I use tools like TortorisGIT, it's easy to git a broken repo.

Because TortoiseGit is the absolute worst tool for the job. It's a hack trying to make Tortoise SVN to work with Git. Which is why it doesn't support 1/2 of what Git actually supports and you have to do it from the command line.

GitExtensions is much better.

After all git's goal is that you have all sorts of personal distributed repo's

No, that's not true at all. But it easily allows you to fork the code and have merge requests. That way someone can completely go their own direction and people can build off of them without forcing everyone through the central SVN.

[kb1gtt]

You're better off using a command line than trying to figure out that GUI. To use that GUI, you first really need to know the low level details of GIT, then you can try to figure out how to click the buttons in that GUI to get the command line written how you wanted it. As it stands now, I haven't seen any GIT GUI that's wroth while for windows. No worth while GUI for windows is a problem for most of the world.

GIT is also plagued with having the repo owners telling others how to use GIT. It's very common that you spend more time debating how to use GIT than you do in actually doing check in's.

GIT does not allow locking of files, which is what makes it only designed for single operator use. Because you can't lock files, you can't accurately control when the files might be modified, as well you can't assign ownership to a users account. Because of this, you can't have more than one person with check in rights to a repo. SVN can be both decentralized, as well as centralized. GIT is only decentralized.

As it stands now, there are very few people contributing code, so it's really a mute point. We'll see if any worth while work comes from GITHub affiliated helpers. At least now we can measure if these folks that have been complaining about using GIT are just complaining, or if they might help the project grow. In the past I've seen very little help from others on GITHub for this kind of project. I've only see GITHub as a very mild marketing tool. You can pick up some advertisement by having it up there. It's not much advertisement, but every little bit can help spread the word.

[kb1gtt]

GitHub apparently has an issue with employees claiming it's a hostile work environment. I tend to feel that's the situation with many of it's members, but apparently that goes up the chain. One of the founders has resigned. I have not been a fan of opensource bullies for some time now, I'm glad to hear that github is taking action against bullies, but there's still a long way to go.

https://github.com/blog/1823-results-of-the-github-investigation

[20div0]

There is a happy medium here -- git svn. It is very usable. I used it for a long time at work and it makes svn usable.

You can clone like this:

Code: Select all

git svn clone http://svn.code.sf.net/p/rusefi/code rusefi-code -s --prefix=svn/

Then, you can work on you own local branch and generate patches from git and email that out to russian to be review and commit to the svn repo.

But you are not kidding about sourceforge's downtime, I cannot complete the clone using the svn:// url and keep getting connection unexpectedly closed error. End up using the http:// URL and it is cloning fine. The svn in sourceforge seems very unreliable....

[AndreyB]

I've just setup hourly mirroring of rusefi@SF into https://github.com/rusefi/rusefi

github is definitely easier for contributors in case any would appear

[AndreyB]

https://sourceforge.net/ is down more and more often

Down-ish again. Good job SF, it has been 6 months of relative stability!

[kb1gtt]

Has anyone created a good graphical git tool yet? Or are the end users still limited to a command prompt?

Features I don't like about git, include you can't lock a file and share access to the repo. There is one owner of that repo, and the repo can't be used to control who has control over certain files. Then gid doesn't work well fo binary files, it's really only good for text files. In my case most of my stuff is solid modeling files and other binary files. Also if you need to hand over control of a repo (leave a job, or pass off a project) other developers have to either move the repo they pull from, or you have to give someone your password. I'm not a fan of giving someone my password and often you need to have one controlling repo to maintain regulatory pedigree purposes. So when regulatory requires the same pedigree, I would have to hand off my password which is yuck.

I think git works well for Linus, which was specifically developed because of his concerns with security, and was tailored to his specific needs and desires. For most applications out there I think git is stupid.

I'm not saying SVN is better or anything like that, both tools are well stupid from my point of view. If someone could make a good graphical tool, and if they could make git play nice with binary files, that would be fix most of the stupid issues.

Any how I'm not trying to turn this into a git bashing. I'm interested in a quick learn if git has become more user friendly. If not then we can move on and develop instead of talking about shed color.

[spags]

I don't mind the discussion but it's getting a little OT. I'm always open to using newer better tools (if they are actually better).

I use git gui for commits and gitk to find my bearings, they look like sin but get the job done. Still do a lot of things through the shell but it's all broken out through git gui.

As for binary files, its a source code management system. Not an archive system, it can't diff and merge binary files so it doesn't try to. It detects a change if the checksum changes. Wont barf them up and get handled like any other content when moving code around, except don't expect it to merge.

Sharing access is broken in git, because it's creators think sharing access is broken. Every repo is just as valid and people can push and pull code from each other, its up to the organization to denominate release managers and testers, they will shape their repos accordingly and share code. For example I usually have a stable branch (where the release manager pulls from), a normal development branch (where other programmers pull from) and a bunch of freaky, no idea if it will pan out branches (these I share with whomever I'm working with). The idea is I always merge my changes into stable when they are ready and that's there q/c is done before they are integrated into production. It's up to me to merge my code with current development before I make it available to them.

This everybody has their own world philosophy can be a problem with large multi-component projects if they live with just one repo. And git in itself doesn't address those issues. The linux kernel is huge but if you think about it it's just one component. Another large project that uses git is android and google had to create a wrapper around git called repo to address these issues.

As for git being user friendly.... once you get the flow of it it stays out of your way, code just flows and you don't have to dick around with it. However it's a pretty wierd flow and it takes some getting used to. I don't code on windows so no idea how good the port is, but there was a git for windows port that had it's own bash and ssh along with git gui and gitk, it even did line ending conversions for you to keep shit sane.

[kb1gtt]

Thanks russian for moving this to a more OT area.

I hadn't heard of gitk. I'll add it to my list to try some day. Thanks for noting it. I have used gitgui, it was one of my better experiences with git, but was still lacking. My best and worst experiences where with TortiseGIT. It was nice and user friendly in windows, and when it went wrong it could self correct most of the time. Or at leas it could when it was my own work. When ever I had to merge someone else's work, it got really messy, and sucked up lots of time.

If you're pro git, I'd say keep making contributions in git land and eventually russian will have to make me come to the dark side Until more people contribute via git, I'll just keep looking for a tool that's efficient, and I'll keep using a tool that efficient for what I'm doing.

[spags]

Cool, I hadn't seen this thread. And here was I trying be all political and stay on topic. Not anymore.... .Here follows my full opinion of git vs svn. This is a long rant, you've been warned. I would like to start by clearing some stuff up:
1) You guys have done great, and whatever scm you use has had minimal impact on what you've accomplished and it will keep being that way
2) Programmers are passionate about their tools. Editors and source code management (other than language choice) are the biggest decisions a programmer makes on what kind of tooling they use. Even if they end up being close to inconsequential they matter to that human part of us.
3) Git = decentralised SCM, Svn = centralized SCM. These terms are used interchangeably.

SVN vs Git
Synopsis: Centralized SCM (read svn) is shit, De-centralized source code management (read git) is less shitty. Use git.

Why is SVN shit?
SVN is a fine code archival program, but it can't branch worth shit. Once you have more than one commiter it becomes unwieldy and it requires a very coordinated group to keep things straight (I would not call open source voluntary development very coordinated). That's why most svn projects avoid branching and only do it when absolutely necessary. And then its mostly unmergable branches. Like release branches where the code gets back ported from mainline to do bugfixes and maintenance releases. Notice that branches in svn are more like placeholders where code goes to die because merging is so painful. Why is merging painful you might ask? Well because people (OS programmers specially) tend to want to do whatever crazy thing they feel like that day. When you have multiple people committing into the same repo they tend to fuck shit up, this in turns pisses off the lead devel because it breaks his house of cards and adds management overhead to a project. When more than one person sharing one repo it's basically a race condition constrained by politics. It will always break.

Why is Git less shity?
Instead of trying to make everybody live harmoniously in one repo, git embraces the chaos and lets people do whatever they want in their own little world. They only have to agree at the point of exchanging code, nobody inflicts anything on anybody. If a repo won''t merge with my code, i just tell the developer to fix his shit or it wont go in. Or if i feel benevolent (or the other developer is the lead). I pull his code into another branch and merge it into my stuff. This seems like a lot of work. It isn't, these systems are built to find the best merge path to and from different points in the tree. All you have to do is make sure those paths exist. It's still shity because you have to talk to people and agree on how things are going to be done. You have to be mindful of where you are in the tree and how your code will find it's way home to mainline, this becomes second nature after a while, like driving stickshift. But this way you don't break the tree when you cock it up.I see kb1gtt's comments about git being hard to learn. He's right, but the same can be said for any good tool, in his side of the project it's oscilloscopes, voltmeters, test circuits, EDA programs... etc. None easy to use but very powerful and easy to use once you know your way around them. For storing binary bits and bobs (like the ones in the hardware directory), it sucks just as bad as any other scm. Binary and scm don't work together and I don't know how to solve it. It's one of those things you just have to work around .


Use git?
Using git as a group is not as hard as it looks but you have to stop expecting svn things from it. File locking in git is a non-sequitur for example; so is version numbers and linear code paths. Embrace branching and merging as the main way to share code. So what would development look like in a de-centralized rusefi world? Here are a couple real world examples, isolating large changes in the code and filtering contributions, i leave implementing those things in svn as an exercise to the reader:

There is a new version of ChibiOS, it makes coffee and give bj's so of course you really want it managing your engine. The proper way to do this IMHO is to branch off into a chibios_upgrade branch, break the codebase all you want and make it fit. Meanwhile the mainline known as "master" in git parlance only takes in higher level changes and fixes that won't be touched by the chibios upgrade (like the next example). You can merge those changes from master into the chibi_os branch as you do the upgrade if you like. Then once the chibios_upgrade branch is ready to be used by the rest of the coders; merge it into master. The system will understand what the merge path is and just do it, provided that you haven't done any chibios specific changes in master, even then there are things called merge strategies that allow you to specify how merging is to occur and over-ride changes depending on the merge direction.

Spags freaky a/c code, some crazy programmer lives down in the caribbean where it's always warm and he want's a/c. So he writes this a/c controlling code, some of it looks good but you're not sure about other things. You have two options, you can ask him to modify the code and change the things he doesn't like and put it in a for_mainline branch. You check that the code fits your criteria and merge it when it's ready. When he updates his repo to yours; the code will have come full circle and nothing will have broken, the system will just get it. Option two, he's an asshole and tells you to fuck off if you don't want his perfect code (not really but i'm not calling anybody else an asshole). You tell him to fuck off but then comes summer, it gets hot and there is newfound use for that code. You pull his code into your repo, hack it up on a incoming_asshole branch and once it's ready merge it into master. Again the system gets it.

These are things that have happened and are going to keep happening, i think de-centralized code management offers the saner solution to these insane problems.

P.S. How hot does it get in russia, do you guys even need a/c?

[AndreyB]

sourceforge is down again for more than 24 hours. This is probably related to https://sourceforge.net/blog/small-but-significant-changes-to-project-pages/ but it still sucks.

I've made a mistake to host some documentation images in SF SVN - so at the moment half of http://rusefi.com/wiki/index.php?title=Manual:Hardware_Frankenso_board page does not display.

I will begin migration to github by trying to pointi wiki pages at github using their SVN option.

[mobyfab]

Maybe it's time to finally move to github and get 10x contributions and visibility
spags is 100% correct.

I would like to have a look at the code but SVN is just a big NOPE for me. I'm probably not the only one.

[kb1gtt]

This has been on github for some years. See this page https://github.com/rusefi

I think we have gotten 2 or 3 contributions via git repos.

[mobyfab]

Yes but it's a mirror, there's no way to merge pull requests and the commit history is simply broken.

Basically it's almost useless in the current state.

[kb1gtt]

I'm probably going to bugger it, but SF is working again.

[AndreyB]

github kind of has an SVN bridge but it does not really work with Jenkins - https://issues.jenkins-ci.org/browse/JENKINS-6368 - looking for a workaround for a simpler transition

[AndreyB]

I am tired of SF instability - being unable to commit for more than 24 hours at a time is just deal breaker for me.

As of today https://github.com/rusefi/rusefi is the official repository

implementation details:
personally I am developing GitHub SVN bridge.
GitHub SVN bridge does not work for Jenkins, and more importantly I want consecutive build numbers - so for now Jenkins would work be syncing github into SF, and build system would work based of SF. That's a temporary solution.

TODO: resolve line ends for hardware source files, source code line ends are OK already.

[mobyfab]

This might help: https://github.com/cmungall/gosf2github

[AndreyB]

This might help: https://github.com/cmungall/gosf2github

All tickets migrated to https://github.com/rusefi/rusefi/issues using https://github.com/cmungall/gosf2github

Let the rainfall of contributions begin!