On 26/04/2011 4:59 AM, Vincent van Ravesteijn wrote:
It would be possible to use svn/git together for one release cycle. I've
been maintaining a git repo parallel to the svn repo for the last few months.
However, everyone needs to become used to using git, we need to decide on
a place to host the git repo, the maintainer needs to design a appropriate
workflow that we all agree on.
I don't feel the need to move to git. At all.
If you think of moving to git because of branch management, I would
strongly caution against that. Branches are too much burden. You want to
avoid them at all costs. The simple fact that git encourage them makes
me want not to approach it.
The reason I feel this way is that merge conflicts happen, they are bad,
and it does not matter what system you use for versioning, you will
spend extra time to resolve them. The earlier you realize you have a
merge conflict, the easier it is to fix. But with branches and the git
philosophy, it seems totally reasonable to work on your own for months,
until your feature is ready to merge, and then it's one more month to
get it in. I have seen this happen, I am not making this up.
For this I've tried to adopt the Git development model:
- All new commits are committed into a feature branch:
e.g.:
vfr/fix-table-width, baum/layout-translations,
younes/redo-spellchecker-ui ...
Please, actually only some new features really deserve branching.
- These features are regularly merged into a development branch.
ok, if you police the developers to do it.
- When a feature is complete, well tested, well documented, has a test
accompanied with it and when it has clear commit logs, the feature can be
merged into either experimental/trunk/maintenance and so forth.
So who is doing the testing on your branch? it's just you then.
Git uses another level in-between, but I think that is a bit too much
given the fact that there are not that many developers testing other one's
features to the bone. We just don't have manpower to do that.
There are certainly benefits.
- Less noise in commits: a new feature in SVN sometimes comprises over 20
commits or so. When using Git, we can cook a certain feature until it is
complete and commit it as 1 merge consisting of a number of commits which
are logical steps in introducing a feature. As a result we have less commits
in
history saying: "Fix thinko in previous commit."; or "Fix bug #xxxx." which
is
a bug which would never have existed if it wouldn't be introduced in SVN in
the first place; or "Add a comment for rxxxxx"; or "Revert commit rxxxx"; or
"Revert unwanted commits in rxxxx" and so forth.
How does that hurt? And how does git commit #4326iku63r2bv9q2o35489 help
in tracking commit numbers?
- It's easier to backport certain features to older branches.
Certainly that's true. But avoid branches, and you don't need this.
- We can think of having several branches: e.g., LyX3.0 (or experimental)
/LyX2.1 (or development)/LyX2.0.1(or maintenance)
This is fine. In fact this is already the case I would say, since some
devs already have experimental git branches.
- A clearer separation of commits to docs, translations, layouts, etc from
commits to the cpp code.
Could be useful, indeed. I'm not sure how git helps here, and if some of
the ideas done in git apply to svn as well.
From my first experiments it seems that in the last few months, there are
only 20-30 topic branches needed. All commits are related to each other
within a certain feature or are 'development' commits like cmake/makefiles/
installers/release-notes/credits or are commits to doc/translations/layouts
and so forth.
20-30... Ouch. Again, who is testing branch 17? Who spends the extra
time merging this and that?
Furthermore, we should have a clear development strategy. We need to
track which features we aim to introduce for the next release, we need
to keep track of the status for each of the features, so we can either
decide to drop the feature or decide to draw attention to it and speed
up development. Now, it happens that there are half-baked features in
trunk... and we have a problem when a release approaches to get them
either in a reasonable state or to remove (disable) them.
Opinions ?
My opinion is that the best way to use git would be very short-lived
branches. I wouldn't mind doing it this way: "Hey guys, here's a pull
request that fixes bug #1234, can you try it out and push it in?"
In other words, the same as "Hey guys, here's a patch that fixes bug
#1234, can you try it out and commit it?"
So svn is just fine.
--
Julien
