Proper usage of version control systems like Svn/Git, etc

[Sebbi]

Hey there,

over the last few days I tried to merge the _shared branch with my changes, so a patch can easily be made. I noticed a few things about how the svn repository is being used and have some suggestions:

1) don't EVER replace something by commenting out old code and adding the new code above the section. It's the whole point of having a version control system to be able to go back and see old code. There is no need to do this and it confuses everyone because now it's not a change, but an addition in the version control system ...

2) don't leave debug stuff in your commits. I wondered for minutes why the debug[] variables were showing unexpected values until I found out that they were set in getEstimatedAltitude()

3) could we finally move to a distributed version control system where everyone can work in their own branches and locally commit (so #2 doesn't happen) and use the version control even if they don't have write permissions on the actual repository?

Sorry, don't mean to insult anyone, but #1 drives me crazy! Even more crazy than #1b which would be pasting code in a comment that you then adapt and commit it with the comment included
Feel free to ignore this rant ...

[timecop]

On top of that, I'd like to request people to stop writing shit like this:

Code: Select all

else if (rcSticks == THR_HI + YAW_CE + PIT_CE + ROL_LO) {conf.angleTrim[ROLL] -=2; i=1;}

This does NOT make your code run faster.
However it makes looking at your diffs REALLY ANNOYING AND DIFFICULT.
It costs nothing to press enter and properly indent stuff - and makes the code 100% more readable.

Code: Select all

else if (rcSticks == THR_HI + YAW_CE + PIT_CE + ROL_LO) {
  conf.angleTrim[ROLL] -= 2;
  i = 1;
}

kthx

[Mis]

I not agre. Sometimes this style is better readable, especially if several similar statements are arranged one behind other.

[timecop]

I not agre. Sometimes this style is better readable, especially if several similar statements are arranged one behind other.

Until it's time to change that code, which makes the diffs unreadable.

[copterrichie]

What is good Coding Practice? Have anyone DEFINED exactly what that is?

[Sebbi]

Just use google with the keywords "good coding practices" and find something like this, which gives a nice overview:
http://net.tutsplus.com/tutorials/html- ... able-code/

I agree with timecop that proper indentation is necessary for version control systems to track changes, but I also understand that you don't want to have spaghetti code with over 1000 lines of code. Maybe MultiWii.ino needs to be split into several files for global variables & loop functions to make the code more readable. But that's something for another time and thread.

The rant was more about commit practices, but I am sure Google will find some best practices for that, too

[copterrichie]

Over my lifetime, I have seen many variation of coding practices, it is all very subjective period!

The thing to do is, this community come together and agree what is the best coding practice for this environment instead of one person or clan dictating what it should be.

[fiendie]

Over my lifetime, I have seen many variation of coding practices, it is all very subjective period!

The thing to do is, this community come together and agree what is the best coding practice for this environment instead of one person or clan dictating what it should be.

Of course it's a matter of debate.
But the keyword is consistency!
If you have more than one person working on a project it is crucial that everyone adheres to the same conventions right down to the level of where to put curly braces after an if-statement. Otherwise merging code will be a nightmare.

You have to admit that "No Classes" and "As few tabs in the Arduino IDE as possible" is not much to go on.

[copterrichie]

Then create a thread or use this one to DISCUSS what the PRACTICE should be and ask everyone to adhere to those standards INSTEAD of dictating.

[fiendie]

Then create a thread or use this one to DISCUSS what the PRACTICE should be and ask everyone to adhere to those standards INSTEAD of dictating.

Well, isn't that what we're doing already?
Since no one here is actually in a position to dictate anything.

[copterrichie]

From my observation window, it appears as if the Clan is telling others how to code. hmmm.

[shikra]

Alex decision IMHO if any changes... He's the guy who created this beast and has to put up with all our request to merge our preferred bits of code. Poor guy.....

Lets not forget MultiWii has managed to produce many versions over the 2+ years that Alex brought this to the open community. It can continue even if no change...

[fiendie]

Alex decision IMHO if any changes... He's the guy who created this beast and has to put up with all our request to merge our preferred bits of code. Poor guy.....

Lets not forget MultiWii has managed to produce many versions over the 2+ years that Alex brought this to the open community. It can continue even if no change...

I think you're missing the point.
Why are you people always so afraid that someone is trying to take something away from Alex? Noe one is... Or are you just trying to score some points? Because it is getting annoying.

Sebbi made some very good points why it would be a good idea if all devs follow some basic style guide. It's just collaboration 101... There is a big catalog of best practices but some stuff is very much open for debate. So how about letting the debate run its course instead of crying wolf all the time?

[copterrichie]

Alex decision IMHO if any changes... He's the guy who created this beast and has to put up with all our request to merge our preferred bits of code. Poor guy.....

Lets not forget MultiWii has managed to produce many versions over the 2+ years that Alex brought this to the open community. It can continue even if no change...

Amen!

Why is it that some people can not see the accomplishments of others, but yet, they always have something negative to say?

[msev]

In my opinion fiendie has not said anything negative towards no-one...He has merely put some suggestions about good coding practice...In pharmaceutic industry we have to strictly follow GMP guidelines...Maybe that could be good also for coders .. Again, I haven't sensed anything harsh from fiendie's side..

[copterrichie]

The bottom-line is, there are as many coding practices as there are variances in language. when you have a few clans that thinks they are superior to others and bash others accomplishments in private or in public does not help the issue. That is one of the problem with community effects, that is subjectiveness and everyone view themselves as being right and everyone else is wrong. The term, collective effect, just does not seems to be understood.

Yea, TC I feel like BLOGGING!

[Sebbi]

Uha, while I agree that some coding style guide is not a bad idea, I think MultiWii does just fine in this regard. The codebase is small and I managed to understand what the code does very quickly, so I have no problem with the current "style" (or non-style however you want to call it).

What I meant was the usage of version control systems and how this can be improved, mainly the "i commented something out in case we need it later and added my stuff" practise. Just take a look at those two commits to see what I mean:
http://code.google.com/p/multiwii/sourc ... ltiWii.ino (one big addition of code)
http://code.google.com/p/multiwii/sourc ... ltiWii.ino (one big removal of code previously commented out)

I think this practise comes from everybody commiting to the same branch and having no local version where they can try things out without confusing others. It would still be bad practise then, but at least it would be hidden in some (local) branch nobody can see and the next public commit would be a clean replacement of code so the VCS know it is a replacement.

And that's where distributed VCSs like Git come in. It is relatively easy to convert Google Code SVN repositories to Git, but I prefer Github over Google Code (more features) and many others do, too. However ... a Git repository doesn't care where it is cloned from, so ... whatever. Please understand that Git isn't the holy grail to solve all problems, but I think it is much better suited for distributed development and the pull request features and statistics on Github just KICK ASS

Let people code however they want. It's not like this is a very huge project or software that's going to space or in an operating room. There need to be only some guidelines on what to commit so the version history and merging doesn't get ugly.

My 2 cents.

P.S.: Nobody is bashing anyone here ... it's not a 32 bit vs. 8 bit thread afterall

[Sebbi]

Or this commit: http://code.google.com/p/multiwii/sourc ... ensors.ino

[fiendie]

The bottom-line is, there are as many coding practices as there are variances in language. when you have a few clan that thinks they are superior to others and bash their accomplishment in private or in public does not help the issue.

Yea, TC I feel like BLOGGING!

OK, you're trolling again. So that's settled then.

But I'll bite just to make my point very clear and in case anyone is taking you seriously.

* There may be many coding practices, but you just threw that in there without stating any meaningful differences between them. The point here is: It would be better to agree on ONE of them as opposed to just making shit up as you go along
* Everyone is entitled to his own opinion but tell me if you agree with this simple statement: It is better if everyone working on the same codebase adheres to the same rules, REGARDLESS of what these rules may be. You are insinuating that the point of this discussions is to tell other people WHICH coding style they should use which is, of course, bullshit and you know it.

That is one of the problem with community effects, that is subjectiveness and everyone view themselves as being right and everyone else is wrong. It is a collective effect that just does not seems to be understood.

I'm sorry dude but that is just mumbo-jumbo. Do you actually read what you post? Or is it all just James Joyce-style stream of consciousness?

[copterrichie]

Ha! Do you read contractual agreements before clicking the OK button? Get real and as for your trolling statement, you know where you can put that.

[shikra]

?? Not sure what your problem is exactly. Seem to have taken a dislike to some posters. Fully respect Sebbi, his posts and suggestions. Agree with most of them too. He is a good guy. I don't know where you get that impression.

Don't have time for trolling. Don't expect a reply.

Alex decision IMHO if any changes... He's the guy who created this beast and has to put up with all our request to merge our preferred bits of code. Poor guy.....

Lets not forget MultiWii has managed to produce many versions over the 2+ years that Alex brought this to the open community. It can continue even if no change...

I think you're missing the point.
Why are you people always so afraid that someone is trying to take something away from Alex? Noe one is... Or are you just trying to score some points? Because it is getting annoying.

Sebbi made some very good points why it would be a good idea if all devs follow some basic style guide. It's just collaboration 101... There is a big catalog of best practices but some stuff is very much open for debate. So how about letting the debate run its course instead of crying wolf all the time?

[fiendie]

?? Not sure what your problem is exactly. Seem to have taken a dislike to some posters.

OK, putting words in your mouth was a cheap shot and I apologize.
But my problem is that a lot of threads - especially critical ones - get derailed by people coming in and saying one or both of two things:
* "It's the project owner's decision!" - Which is just stating the obvious
* "It worked before without [insert matter of debate here]" - Well, sometimes circumstances change...

Both of those statements don't add ANYTHING to the discussion, which can be a bit frustrating at times.

And no, I only particularly care about the version control and the way it is handled in MultiWii, not posters.

[fiendie]

Ha! Do you read contractual agreements before clicking the OK button? Get real and as for your trolling statement, you know where you can put that.

Aw, SO sorry. Must have hit a nerve there.

So how else should I interpret your little blogging-reference?
Should I post some IRC chat logs?

It's getting old...

[nicog]

Ha! Do you read contractual agreements before clicking the OK button? Get real and as for your trolling statement, you know where you can put that.

copterrrichie, you should quote yourself from time to time, don't you?

[copterrichie]

Awe, the CLAN is exposed! You folks need to understand that all people do not dance to your music nor play your silly games. Ha!

Sit in your IRC chat room bashing people and their contributions. No time for that crap!

[Sebbi]

Kindergarten!

Nobody is bashing anyone here ... this thread was only meant as a suggestion, so it is less painful to keep patches in sync with current development for people like me, who like to experiment and may want to contribute something back to this great software project without going so far as to wanting to become a member of the core development team. Just a few patches here and there in the spirit of open source. And some commits do make it difficult to track changes. That was my whole point

Now back to flying/testing

[Sebbi]

Take a look at those two commits:
http://code.google.com/p/multiwii/source/detail?r=1220 (added Alarms.ino from shared to normal MultiWii)
http://code.google.com/p/multiwii/source/detail?r=1221 (two files deleted)

And now tell me that you like the way subversion logs the changes, e.g. nothing got logged. For trunk/MultiWii a Alarms.ino appeared out of thin air without any commit messages from _shared.

Had a distributed version control system be used all commits would have survived a merge and everyone could comprehend what happened when and where. Just saying ...

Same goes for this commit:
http://code.google.com/p/multiwii/source/detail?r=1187 (synced shared to trunk/MultiWii)

Absolutely NO history of all the changes was preserved, so nobody knows what was added when and by whom or why (no commit messages). This is not how version control should work or be worked with :/

[Alexinparis]

Take a look at those two commits:
http://code.google.com/p/multiwii/source/detail?r=1220 (added Alarms.ino from shared to normal MultiWii)
http://code.google.com/p/multiwii/source/detail?r=1221 (two files deleted)

And now tell me that you like the way subversion logs the changes, e.g. nothing got logged. For trunk/MultiWii a Alarms.ino appeared out of thin air without any commit messages from _shared.

Had a distributed version control system be used all commits would have survived a merge and everyone could comprehend what happened when and where. Just saying ...

Same goes for this commit:
http://code.google.com/p/multiwii/source/detail?r=1187 (synced shared to trunk/MultiWii)

Absolutely NO history of all the changes was preserved, so nobody knows what was added when and by whom or why (no commit messages). This is not how version control should work or be worked with :/

As mentioned in the README.txt fine, the repositories multiwii and multiwiiconf are "Alex working area".
It was at a time I thought I could (and have time to) deal every single atomic modification.
But in fact I work only in the _shared part. I realized I've no time to maintain a variant, the recent change here was just to sync things.

The only relevant part to follow changes is the _shared repository.
For this part, I consider svn is enough and does well the job.

[Sebbi]

And another commit:
http://code.google.com/p/multiwii/source/detail?r=1182

Apart from some indentation a lot changed in this commit, but NO commit message of what was done?

I know we all do this just as a hobby, but the organisation and use of this subversion repository is just mindboggeling (why has everyone access to _shared which is effectivly what "trunk" would be in a normal repository?)

Would it help this community if someone wrote short "Howto use git", "How to convert to git" and "How to organise a git repository" guides? Git isn't that different from subversion (e.g. difficult to learn) and if you used TortoiseSVN on Windows, you'll almost feel at home with TortoiseGit

You can painlessly try it with the mirrored _shared branch on Github. Just fork it, clone it to your harddisk, create a new branch, implement a feature, commit often, push it to Github and diff that branch with upstream_shared. If the Github repository were the official one it would be even easier in that you just would have to generate a pull request. This would add an issue with your code attached to the official repository so everyone can discuss if it's any good. If not you can go back and change it and if the devs decide it is good, they just merge it and you get all the commit messages, etc ...

Doesn't that workflow sound a lot easier and straight forward than what has to be done with subversion, today?

@Alex: I am aware that subversion is good enough for most things (if handled correctly), but what it can't do is preserve merged commit messages and allow people to easily submit patches from their own repository without having write access. In fact, nobody needs to have write access to the master repository ... that's the beauty of git/Github

[Danal]

(why has everyone access to _shared which is effectivly what "trunk" would be in a normal repository?)

The _shared directories in the Trunk were created as a "marshaling point" prior to Alex's own merge point, which are the non-prefixed directories. Multiple people have commit access so they can stay in sync. Alex can look at it at any point in time. Prior to _shared, people had to email him changes, or he had to troll multiple branches, or..., or...

Perhaps there is a better workflow, or tool, or whatever. But until Alex himself decides... the general workflow is to use _shared as a collaboration point, and for Alex to integrate from there.




Oh, and for what it is worth, I agree with the three suggestions in the first post. They all make the existing usage of svn more readable and more controllable.

[Sebbi]

I know about that distinction, but it looks like Alex doesn't have much time to keep his trunk version up to date with what is happening in _shared. And because everyone is editing _shared it would be very hard for him to exclude features from there in his version. If every developer would maintain features in their own branches, the community could quickly decide what a good feature/fix/improvement is and Alex can merge it with trunk (or master in git-language) sooner. The way it is now _shared is effectivly trunk with multiple people doing their thing and Alex just copied all the stuff from there into his directory (and he said it himself - above - he has no time for a variant ... so ...).

I have no real objection to using subversion, but still think Git would make things a lot easier. Especially because everyone then has a local repository, can easily branch (that works with subversion too, but isn't used here) and Alex (and/or the community) can cherry pick what gets included in official MultiWii while it's up to the maintainer of branches with features that don't get accepted to keep them synced with master (trunk). AND - perhaps one of the most important features - it encourages drive-by-development. Imagine someone implementing a small feature and it gets forgotten in the forums. Let that happen more then once and that contributer is gone forever ("it's all for the trashcan" like forum user cGiesen put it in another thread). MultiWii states on its homepage that "[...] it’s [open source] the best way to encourage creativity and to spread the developments.". Drive-byers (like me) can be a good way to spread the development and developing a patch requires local version control anyway. So before setting up my own subversion or git repo here, I just clicked on "clone" on Github and everything was setup and ready to go

[Alexinparis]

Hi,

If every developer would maintain features in their own branches, the community could quickly decide what a good feature/fix/improvement is and Alex can merge it with trunk (or master in git-language) sooner.

Ok lets say it happens.
How to deal with incompatible features ? (example: the same MSP number for a new message)
How to deal with similar ideas for different implementation ?
How to deal with partial implementation ? (where only some part of the code are worth to be integrated ?)
How to deal with features where there is no interest ? (at least in the committer list)
How to deal with code that don't follow the main line (for instance, indentation, sort on int declaration variable, code using C++ class, ...)

In fine, someone has to decide / merge / make coherent the whole project.
I don't see here clearly why git would offer a significant advantage.

AND - perhaps one of the most important features - it encourages drive-by-development. Imagine someone implementing a small feature and it gets forgotten in the forums.

Many major improvements in multiwii where given without any version control tool.
I personally like the way some features where added:
"here is the portion of code to change, just test it and tell me;)"
10 times: "yeah cool, it works fine, I like it"
and it gets in fine integrated by one of the committer. The basic idea behind this is the way to "feel" feedback and the forum is a good vector for this.

"[...] it’s [open source] the best way to encourage creativity and to spread the developments.". Drive-byers (like me) can be a good way to spread the development and developing a patch requires local version control anyway. So before setting up my own subversion or git repo here, I just clicked on "clone" on Github and everything was setup and ready to go

Yes it's open source.
open = free for all to use it / test it / modify it / discuss about it / improve it.
source = one main repository with people behind
open does not mean every idea must be taken into account inside this main repository. And I understand it could be quite frustrating some times...
but open = free for other repositories/branches/variation.

[Danal]

If every developer would maintain features in their own branches, the community could quickly decide what a good feature/fix/improvement is and Alex can merge it with trunk (or master in git-language)

That's exactly where we were before _shared... and it bogged down about 4 or 6 branches to look at...

[Tommie]

Hi,

If every developer would maintain features in their own branches, the community could quickly decide what a good feature/fix/improvement is and Alex can merge it with trunk (or master in git-language) sooner.

Ok lets say it happens.
How to deal with incompatible features ? (example: the same MSP number for a new message)

How are you coping with that now? (you don't, stuff just breaks - or you fix it by hand, stuff works)

How to deal with similar ideas for different implementation ?

How are you coping with that now? (one implementation wins and gets merged into the mainline, git offers the bonus that you can actually *test* those various implementation easily. And not only you, but everyone else.)

How to deal with partial implementation ? (where only some part of the code are worth to be integrated ?)

You'd simply just merge the parts you want to merge.

How to deal with features where there is no interest ? (at least in the committer list)

Just like now. Leave them to rot.

How to deal with code that don't follow the main line (for instance, indentation, sort on int declaration variable, code using C++ class, ...)

How are you coping with that now? Either correct it yourself, or (better) contact the developer to fix their stuff before merging it. It's as simple as that.

I don't see here clearly why git would offer a significant advantage.

Because git actually does merging. SVN does not. Copying files around is not "merging".

I personally like the way some features where added:
"here is the portion of code to change, just test it and tell me;)"
10 times: "yeah cool, it works fine, I like it"
and it gets in fine integrated by one of the committer. The basic idea behind this is the way to "feel" feedback and the forum is a good vector for this.

Except it doesn't work. There is no easy way to test a specific change. With git, everyone has a complete and working tree of the source. I can just switch my tree base to a modified version of someone else, merge my config onto it and test it. They can easily integrate those changes into their own code base. With SVN, you are back to copying files and glueing patches together.

[Sebbi]

Git is no magic bullet that solves all merge issues and other problems that development with multiple authors cause. The advantage of git is (1) its distributed development support and the things sites like Github or other git hosting services offer, like (2) pull requests and (3) issue trackers.

At the "how to deal" questions ... what Tommie wrote.

At the end it comes down to some guidelines at how to use whatever version control system MultiWii uses. Continuing to use subversion makes it more difficult (since there is a git-mirror it's not much of an issue), but it worked in the past. Using git would make things easier for drive-by-ers and includes local version control for everyone wanting to submit patches (and lets not kid ourselves, doing anything of value without some version control scheme is just crazy) ... well, using git with some simple guidelines on how to use it that is

I am glad that you are least thinking about such a transition ("lets say it happens"). Issue trackers and git will most likely not replace this forum, but it takes code discussion closer to the actual code. And even if it's only used as a bug tracker it would be an improvement.

Hi,
Many major improvements in multiwii where given without any version control tool.
I personally like the way some features where added:
"here is the portion of code to change, just test it and tell me;)"
10 times: "yeah cool, it works fine, I like it"
and it gets in fine integrated by one of the committer. The basic idea behind this is the way to "feel" feedback and the forum is a good vector for this.

And wouldn't it be better if it were more like:
"here is my repository with feature x, clone it to test if for yourself"
a few times: "yeah cool, i merged it with my branch that improves this little thing what do you think?"
10 times: "you guys are awesome and we could follow every step ... it works and we like it"
and whoever (group or just one person) manages the master repository picks it up and merges it from those remote repositories (or someone requests a merge via pull request and it gets merged this way). It makes testing and tracking much easier than code or zip-files with versions of code posted in a forum.

[Hamburger]

The _shared directories in the Trunk were created as a "marshaling point" prior to Alex's own merge point, which are the non-prefixed directories. Multiple people have commit access so they can stay in sync. Alex can look at it at any point in time. Prior to _shared, people had to email him changes, or he had to troll multiple branches, or..., or...

Perhaps there is a better workflow, or tool, or whatever. But until Alex himself decides... the general workflow is to use _shared as a collaboration point, and for Alex to integrate from there.

good points all of them. The current setup effectively establishes a workflow which everyone has to follow. This may be a hindrance to individuals who choose to select and pick features/patches from various sources. But it strengthens the common project code as all developers are forced to constantly go through a comon branch, namely _shared. This way, most of the integration workload is constantly split among the registered developers.

In the past we have had a fair amount of side effects from commits that got discovered quickly because every developer has to constantly update to the common code base and verify the code against their settings and hardware. I would not want to see people trade lists of sites or patches to grab from all over the net to obtain a more or less recent combination supporting their hardware and supported features.

The discussion ponders around the ease of use for those individual developers who prefer their separate branches versus the enforced strength/integrity of the main branch. My choice is clear - I am all for the enforced workflow leading to one common branch, even at the cost of possibly missing a patch that never makes it into the main branch.

[Sebbi]

You probably don't fully understand how git (= one type of distributed version control) works. It is not that different from subversion in regard to having a "master branch". Just take a look at how one can use Git (Github) today and let me write down an example workflow:

• https://github.com/multiwii/multiwii-firmware and there the branch upstream_shared that is synced with the SVN repository is the current "master" (or origin or what subversion calls trunk)
• Next step (only necessary the first time): you can either fork the repository and clone it from there or you can clone it directly to your harddisk, but without push access (more or less what commit does for svn) that's not the recommended way, because your local repository clone can not be accessed by anyone
• You can now locally create a new branch, switch to it and do whatever you want to do. You can commit your changes locally, revert them, whatever.
• When the feature is ready you can push the branch to your online fork and either make a diff or a pull request to origin (the official MultiWii repository which is currently just a mirror, but could be the one) and let people know what you have done and ask them to test it.
• They can now pull/checkout your branch from your fork (the branch on your repository) and test this specific feature without disturbance from other commits that happened in the meantime in _shared
• The final step would be that someone desides to merge it into the official repository. This person can do just that ... merge, resolve conflicts (or ask you to rebase - see below - so you'd resolve the conflicts), and voila ... code from your branch on your repository accepted to the main/official repository

And now to the point where you see a difference between the git way and the subversion _shared way ... there is none. You can and should regularly rebase your fork with the official repository (= bring your fork to the same state) and then you can merge this to your local feature branch. If something got included in MultiWii that breaks your feature or something else, you'll know it the same way as when someone commited something to _shared that makes stuff break (it's how I found out that my small baro improvement wasn't merged correctly).

And when your feature got merged you implement the next one. As a drive-byer you possibly have to rebase and merge from origin (the official MultiWii repository) for some days/weeks until it's clear that your change was accepted or not. But you would have to do the same (track changes in _shared) with subversion, I guess. Only with git you have a full local repository which does it almost automatically.

Integration workload is split the same way as with git and you wont have to combine you MultiWii version from different feature branches and lists of patches (of course not, who would want that?!). The recent version (current _shared, but without everybody commiting directly to it, so it does break less often, but of course Alex can continue this practise and MultiWii core developers commit/push directly for some adjustment phase) would work the same way as it works now and when a release is made you simply tag it and make a branch for it so bugs can be fixed separately from implementing new features.

It's really just about (1) having a local repository to develop with and not having to commit to a central server, (2) a merge history that lets everyone see what happened, (3) the maybe-use of an integrated issue tracker, (4) easier access for one time supporters (drive-byers) and (5) a more functional and beautiful UI than what Google Code offers.

... and (6) some ground rules how to commit stuff so it doesn't break things or confuses everybody, e.g. the reason why I started this thread. While I'd like to see it migrate from subversion to git (Github) ... as long as there is a Github mirror and commits on subversion don't break things, I am happy enough ... but there is a reason everybody and their cats are switching to git or have done that long ago

TL;DR:
Git does the same stuff that subversion does, only better and in a distributed fashion. You can carbon copy the current workflow and do it exactly the same way with git or you can accept some best pratices so development and some of its chaos improves. Some of these practises might also work with subversion as version control system.

[copterrichie]

Why not create a video tutorial for us noobs?

[cGiesen]

Thats a good idea.
In the moment I use GIT only the same way like Googlecode.

[fiendie]

Sebbi basically said it all. But I want to add a few points here and there.
I think the problem is that distributed version control is a bit hard to grasp at first for devs who are deeply entrenched in SVN or CVS.

good points all of them. The current setup effectively establishes a workflow which everyone has to follow. This may be a hindrance to individuals who choose to select and pick features/patches from various sources. But it strengthens the common project code as all developers are forced to constantly go through a comon branch, namely _shared. This way, most of the integration workload is constantly split among the registered developers.

Like Sebbi tried to convey it is a hindrance to *everyone* who wants to contribute and is not in the group of registered devs.
Every registered dev is still forced to go through the same branch.
You make it sound like the point is to not have a core Dev-Team anymore, which it is not of course.

In the past we have had a fair amount of side effects from commits that got discovered quickly because every developer has to constantly update to the common code base and verify the code against their settings and hardware. I would not want to see people trade lists of sites or patches to grab from all over the net to obtain a more or less recent combination supporting their hardware and supported features.

Everyone would *still* have to update from the common code base, i.e. "pull" from the main repository.
The tremendous upside is that you can keep a branch with a new feature you might be developing in sync with the main codebase.

There are quite a few forks from the MultiWii SVN like alexmos which over time diverged too far from the main codebase to be usable.
It's just not possible to continuously integrate new changes into an SVN fork.

With regard to the "construction kit" model you are alluding to: That is of course not what it should come to. You conflating users and potential developers here. It would be the responsibility of the core dev team to integrate the useful ones. With Github you at least have an avenue of doing that easily via Pull Requests.

The discussion ponders around the ease of use for those individual developers who prefer their separate branches versus the enforced strength/integrity of the main branch. My choice is clear - I am all for the enforced workflow leading to one common branch, even at the cost of possibly missing a patch that never makes it into the main branch.

Looking at the commit history "strength" and "integrity" are certainly not the first words that come to mind when talking about _shared
At the moment there is basically no quality control, no coding conventions are in place. If something blows up you even have a hard time figuring out what even happened because often times many commits are lumped together.

Like Sebbi mentioned the workflow could be carbon-copied from SVN to Git. What I would add to that is the following:
On Github you can have teams (oraganizations in Github lingo) which will resemble the core dev team on Google Code.
You could enforce branch-based access control with server-side hooks so that only Alex can push to, let's say a master branch, and every other core dev is pushing his changes to a branch named "shared" or whatever.

Why not create a video tutorial for us noobs?

That would be a bit excessive but a nice Wiki page with pretty pictures would do the trick wouldn't it?
I'd be the first one to contribute to that

[shikra]

I think the problem is that distributed version control is a bit hard to grasp at first for devs who are deeply entrenched in SVN or CVS.

He is spot on with statement.

One of our dev teams has moved from svn to git. So I asked them a week ago for some feedback....
- Appeared at first complex compared to the simple setup them where already used to.
- Didn't have time to learn / got in the way / time with tool rather than developing etc. etc.


So the big question is
How many want to move to git and how many want to stay.
Am seeing maybe 3 want to move.

Are all the long term contributors being quiet because dont' care which direction- or because its already svn - or because not expecting it to change?
Be good to have some views there- either way.

Me - no care because I dont post many updates....
Actually I suppose that really makes me svn because what I am used to! Nothing against git - I agree its better technically...

[cGiesen]

4 want to move

[copterrichie]

There are Tutorials available on Youtube if anyone is interested, here is part one of many.

http://www.youtube.com/watch?v=mYjZtU1-u9Y

[Sebbi]

There are Tutorials available on Youtube if anyone is interested, here is part one of many.

http://www.youtube.com/watch?v=mYjZtU1-u9Y

If you can't be bothered with command line tools (the linked tutorial introduces you to Git bash) Github has a nice Mac (http://mac.github.com/) and Windows (http://windows.github.com/) GUI for git and there is also TortoiseGit and Eclipse has the Egit Plugin. They also have a pretty large help database (https://help.github.com/) which answers the most common questions about how to do things with git.

The main advantage git had for me was the fact that due to its distributed nature working on the same files simultanously was a lot easier since nothing breaks when you commit everything locally. Of course you still have the same problems when you begin to merge stuff together (e.g. changes in the same line of code), but you wont have them with every commit, because someone else commited something in the meantime. True merge and the nice Github UI were the icing on the cake and of course that nobody has to submit patches or copy & paste code change instructions anymore to help out an open source project.

[copterrichie]

Well, I only selected the first one from a list of thousands: http://www.youtube.com/results?search_q ... aYzLbV2iMY

A picture paints a thousand words but a video paints a library.

[fiendie]

Well, I only selected the first one from a list of thousands: http://www.youtube.com/results?search_q ... aYzLbV2iMY

A picture paints a thousand words but a video paints a library.

I can highly recommend a talk by Scott Chacon who also wrote the excellent and freely available Book "Pro Git".

Talk: http://www.youtube.com/watch?v=ZDR433b0HJY&feature=related
Book: http://git-scm.com/book