On 26-4-2011 20:14, Julien Rioux wrote:
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.
It's difficult to have a nice discussion if you start off like this,
but I'll try.
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.
All feature branches are really regularly merged into a
so-called "development" branch or "proposed updates" branch. This
means that the merge conflicts will be presented almost immediately.
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.
I don't think the git philosophy is about working on your own for
months. I even feel this is 180 degrees different from my interpretation
of the philosophy.
You can and should actually commit earlier when using git because
your work will be in a (temporary) branch and not immediately in
the main repository. Other people will be able to see your work,
they can try it, they can give suggestions and so forth.
When using svn, you have to be cautious about what you're committing
to trunk, otherwise you might introduce some serious bugs. You can
say that this doesn't mind because it is trunk and it is not supposed
to be stable, but how are you then expecting people to test the other
features that are already in trunk, if
- they have the risk of losing data,
- or to have to start bisecting to find a stable trunk, and not
being able to update to the latest svn because person X that introduced
this bug is on holiday for a week ?
Also, I don't want half baked features in trunk that we might have to
revert sometime if the feature doesn't get finished or when it seems
that the feature is bad with possible merge conflicts resulting from
this. When using git, you can start a branch and push a half baked
feature there. It won't get into the stable code if it doesn't
get finished or when it seems to have serious regressions.
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.
I don't agree. I used the git development model for a few months and it
seemed that even the most innocent changes were either reverted later,
or they were fixed, or they had some unwanted committed parts, or someone
wanted the style to be different, and so forth. I can give you some examples
if you want, but then I need to search for them.
If you consider the features that won't deserve branching in your opinion,
then they will probably be merged into trunk-stable quite soon and they
are not an annoyance.
- These features are regularly merged into a development branch.
ok, if you police the developers to do it.
Well, we ask a lot of the developers and there is a maintainer that
can do this by running a simple script or there might even be some
commit hook. This depends on the type of project. If you're running
a business, there can be guaranteed to be someone doing this. If a
project moves slowly, it is not much work for the maintainer. Other
project have automated systems that make sure everything is compilable
and passes all tests before it gets merge. And so forth.
I am willing to think of a suitable workflow for LyX if necessary.
- 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.
No. All developers can do that. You can think of automated tests,
people might find bugs, other people just need some more time to
be able to find a time slot to look at your feature.
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?
First, I didn't want to raise the impression that git would help
to track commit numbers.
Second, how does this hurt ? Well, in several ways:
1) If I'm busy for a week or so and didn't have time to review other people's
commits, I come home and may find a possible 100 commits to review. 20 of
these are updates to documentation, 20 are updates to translations and
the generated statistics, then there are 10 only cosmetic commits.
2) After filtering the noise from the real commits, I have to review a commit
that reads "Revert r1 because it is replaced by a better solution in
r2 as was discussed in the thread on the mailing list http://....";.
This means I have to remember or to look up commit r1, find commit r2,
read a thread on the mailing list. Then I have to check whether this
really reverts commit r1 completely, or whether there are some left-
overs. So I need to put these two commits next to each other and look
for potential differences, that didn't look important to the committer
and therefore weren't mentioned in the commit log.
3) When reviewing a commit that looks interesting, I might note a few
things, mail the original author about these. Afterwards it seemed
that it was already fixed 40 commits later in a commit having a log
saying "Forgot this in rxxxx." Or I might be wondering about certain
part of a commit and then finding out that 15 commits later this part
was reverted because it was committed by accident.
To conclude: Some features might consist of, say, 10 commits and it
would be much easier to review if they all got squeezed into 1 or 2
logical commits without noise.
Another point that this might hurt is when use git/svn blame: I've
fixed so many bugs in LyX and I have crawled the history so many times
and you have to believe me that I really often got so frustrated by
useless commit logs like "Thinko in previous commit", "Forgot this in...",
"Revert r.....". These are really useless and cause you to crawl further.
Sometimes it becomes difficult to find the place where they actually
got introduced. If a feature was "ready", "tested" and "reviewed" before
it got merged into the codebase, you would quicker arrive at the point
in history where some line was introduced or conceptually changed.
- 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't. We have a 1.6.x branch and a 2.0.x branch for instance. Even
when using svn. There is no need for more backporting when using git.
- 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.
But if this is the case, we already have the problem of people working
(too) long on a feature on their own.
- 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.
At some point the maintainer sends a mail of the features that are
candidates to get merged into the stable branch. Then, you have
pieces of code, grouped together in features or similar features,
you won't see the commits to the docs, translations and stuff if
you do not look at those branches. In svn you have only one trunk
and all commits appear there in chronological order, not in logical
order.
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?
20-30 branches for almost two months of development is suprisingly
few in my opinion. Consider that these consist of almost 800 commits
in svn.
Of these 20-30 branches, some are obvious changes,
some consist of only changes to translations, documentation,
windows installer, debug code, autotests, administrational stuff.
So, this gives you even less branches that are actually 'real'
changes.
Then of the remaining branches, only, say, five of them are
interesting for me because I'm an expert in this field, or I
have implemented the first version of that feature, or I've
caused the regression that was fixed in that branch.
Having 10 developers reviewing five branches each, leads to
double-reviewed branches.
I rather review a certain branch consisting of logically grouped
commits than to have to dive into 800 commit logs, filter out
interesting parts, combine several commits in my mind to get
the overall picture, find out which commits actually belong
together.
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.
I don't understand why you jump to the conclusion that svn is
just fine. It really doesn't work for the LyX community to ask
for each others comments before committing. People are just too
busy and don't have time whenever you finished a certain patch.
This would mean you'll have to wait endlessly before
committing a patch, over and over again.
I hope this explained my interpretation of the git philosophy.
Vincent
