jiho wrote:
Since this supposes a lot of branching (for SoC, probably also for many large scale changes because the tree still needs to be usable during that time etc.) wouldn't it be a good time to change version control system to something that eases branching and merging?
I branched and merged a lot for GSoC 2007. Merging and branching *is* easy in SVN.
jiho wrote:
Plus, distributed version control would ease a model where changes are reviewed by several people before they are committed to the main tree (i.e. just pull the changes from other people's trees and allow commits to the main tree only by the reviewers).
I am opposed to such a working model. Reviewing would be a fulltime job, and not that much of fun (count me out!). Who will have enough knowledge of allll of inkscape anyway? One of the nice things about TortoiseSVN: when you do an SVN update, you can press the view log button that then shows *only* the log of revisions since the last svn update. This way it is very easy to keep track of what changed recently. Since the log UI of tortoisesvn is quite nice, you can see which files changed click on it to see the diff. Makes for easy reviewing when one wants it (I often check files of which I know the code), but does not demand reviewing.
I am very much against doing offline 'commits', just from what I see happening in practice. Although it is nice to be able to 'save' work when there is no internet connection available, it removes an *essential* part from the workflow: SVN Update and checking whether it still works, possibly checking source code changes. I'm not sure whether everybody does this: 0. svn update 1. code stuff 2. svn update (!!!) 3. make 4. does it work? did merging go well? 5. svn commit
2-5 in rapid succession and needs internet. This at least ensures that we don't get ';' missing buildbreakage etc, but also removes more complex problems. I think any offline CVS method removes 2 to 5.
Regards, Johan