J.B.C.Engelen@...1578... wrote:
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.
It is easy if you keep the proper workflow. But you still have to know something. If you haven't done any work with a DVCS system you should try one out at home with one of your pet projects for a week and see how "easy" branching and merging really can be. In DVCS the system knows which revisions are where so you don't have to keep track, you simply tell it to merge this way or that and it does. No mental effort.
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?
I think I agree here. In the Inkscape project we don't follow such a model. We are very open with committer access and that is one of the reasons for the project's success.
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 think the workflow for a DVCS is a bit different. For example I keep one branch to track the state of the main repo and another branch for each task I'm currently working on (branches rather than separate checkouts). Now I can update the state of the tracking branch as often as I want (independently of my working branch, like you are used to in svn). And because the system knows which revisions are in which branches I can check the log at anytime and get just the new commits by comparing the commits on each branch. In git the command for this is called `git whatchanged`. Also one of the things I noticed is that any use of the log functionality in TortoiseSVN was unbearably slow because it requires network access. A DVCS stores all this information locally, so the logs become much more useful and accessible. I think you'll appreciate this.
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
- code stuff
- svn update (!!!)
- make
- does it work? did merging go well?
- 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.
I really don't understand why you think that a DVCS would cause people to practice any worse VCS hygiene than now. DVCS gives you freedom to commit in smaller logical blocks. As a person who worked with branches in SVN extensively you should understand the utility of this. You likely committed much more frequently on your branch than you would have committed to trunk. The diffs were smaller and easier to read. The commit messages were more granular and more meaningful. And when working on a branch svn update is equivalent to merge. You didn't merge for every commit. You had the freedom to work out an idea while committing bite-sized pieces and dealing with the integration problems when you chose to. But you still dealt with them. As things are now many people keep large sets of changes in their local tree and work, effectively, without the help of version control day to day. Bulia, for one, likes to drop large changesets on us. I think he will benefit tremendously from DVCS. Think of it as a unification of team VCS and your very own personal VCS. A work flow might look like this:
0. check out HEAD branch from central repo 1. branch "topic" 2. code a bit, test, commit. 3. code a bit, test, commit. ... 4. fetch changes from central repo into HEAD 5. merge HEAD into "topic" 6. fix, test, commit 7. code a bit, test, commit. 8. code a bit, test, commit. **finished new functionality or refactoring** 9. fetch changes from central repo into HEAD 10. merge HEAD into "topic" 11. fix, test, commit 12. push topic changes to central repo