Hi,
Apparently I can now commit to the Subversion repository. I have a minor patch available, and I was wondering whether there were any commit policy agreed upon. Do people like to first review the patch? Can I commit straightaway? What should I do?
Are there any other version/revision policies agreed upon? For instance, for the use of branches and tags?
Gerco.
I replied Gerco’s questions in the IRC.
Main reply was this:
This procedure can be shrunk when you’re more experienced with synfig code.
Thanks for your contribution.
-G
I share Gerco’s concerns. With genete and I getting to a point where we’re dangerous enough to write (small) patches, it would be nice to have some guidelines to make sure we don’t go around breaking anything/everything.
Should be submit patches for review before commit (buddy check) or just start committing and relying on SVN to be able to back things out if/when it all goes wrong? Does Synfig have any coding styles/guidelines that we should be aware of?
Reviewing changes before a commit is always a good idea. It’s easy to get stuck on a working but low quality solution. Discussion frequently allows fresh perspectives to emerge. However, reviewing is best done by people with a good overview of the code, and those are, I gather, in short supply. 
Just commiting one’s changes to the trunk, with the option of rolling back, is doable, but can quickly become confusing I think. This might also apply to a lesser degree to patches. The cleanest way would be to commit the changes to a (feature or bug-fix) branch, and merging the end result, after general approval, back to the trunk. Using feature and bug-fix branches makes the trunk a so-called integration “branch.” However, I’ve noticed that a lot of people get confused quickly when it comes to branching and merging.
I guess posting, reviewing, and discussing patches would be a good start.
G.
In the past we haven’t had enough code contributors to need any commit policy. dooglus did commits, I tried to review them where possible and fixed them after if needed. Mostly they were fine or I didn’t understand the changes because dooglus knew the code better than I did.
About commit review, I think that is a great idea. I’d like to propose we use review-board.org/ as a tool for this. Now that django 1.0 is API frozen and the review-board developers are thinking about releasing, so it becomes more useful:
chipx86.com/blog/?p=264
bugs.debian.org/495148
What is your opinion on us switching to git (some info on the source code page)? I find that it helps with code quality because it makes it very easy to get commits right and doing just one thing; local commits to prevent pushing bad patches but still allowing commits, git commit --amend for incrementally improving a change and gitk and git gui for reviewing changes while improving them and just before the push stage.
I’m going to need some Git training to understand how to handle the local commits v. branches, etc. I’ve just got my head around git add, git commit, git push…
Chris
What’s the problem with Subversion (svn)?
Subversion also has branching and merging features, that allow one to commit changes that are still in flux but that you still want to save, without screwing up the trunk, and making the lives other developers difficult.
Git was developed to support the massive influx of patches on a very large code base (i.e., Linux kernel development). Neither of which applies to Synfig. Subversion does have wide tooling support. For instance, I’m using Eclipse and Subclipse too deal with the Synfig code.
I currently don’t see the benefit of switching to git. Am I missing something?
G.
Check out the video of Linus talking about Git:
video.google.com/videoplay?docid … 4603874737
Personally I just cannot deal with SVN after using git. Luckily there is git-svn when I need to touch SVN repositories though.
There is an eclipse plugin for git:
git.or.cz/gitwiki/EclipsePlugin
git.or.cz/gitwiki/EclipsePluginScreenshots
A blog post from one of the SVN developers about its future:
blog.red-bean.com/sussman/?p=90
tech.slashdot.org/article.pl?sid … 09/1528250
Some pro-git posts:
keithp.com/blog/Repository_Formats_Matter/
keithp.com/blog/Tyrannical_SCM_selection/
For me the only bad thing about git is that sourceforge doesn’t yet support it.
git for SVN users:
Yes, I have seen Linus’s ranting and raving before. I was not too impressed. He seems to think that the specifics of his personal workflow apply to everyone. Git maybe suitable for his situation, but I’m not convinced it’s suitable for everone else. I’ve been looking into version control (and configuration management in general) over the last couple of years, and I’ve noticed that most developers (even the smart ones) quickly get confused and loose oversight. And that’s only with centralized systems. Becoming decentralized adds a whole new layer of complexity, making version-, and thus quality control, even more difficult. While the benefits of the decentralized approach can sometimes outweight its costs, I think usually it doesn’t (even though they constitute nice toys).
While there are some things I dislike about Subversion, what features have you been missing (or what misfeatures prove to be obstacles) that would warrant a switch to git (incl. its conceptual overhead)?
G.
It is that extra layer of complexity (and usefulness) that comes from a DVCS (particularly git) that I want.
One particular thing about SVN is that branching and tags feel like an afterthought.
I do understand it isn’t for everyone, so lets stick with SVN for now, perhaps we can revisit this at some point in the future.