"Georg S. Weber" <georgswe...@googlemail.com> writes:
> On 14 Mrz., 20:43, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
>> On 2012-03-14 19:20, Keshav Kini wrote:> If we switch to git, as I
>> understand we eventually will, patches
>> > (commits) made from an older dev release will be considered to "not
>> > apply" (not be mergeable) a lot more often than merely the cases when
>> > other people have meanwhile touched the same files - in fact, *always* -
>> > unless we make development releases based on their predecessors.
>>
>> If this is true, then I don't want to switch to git.
>
> (... scatches his head ...)
> If this was true, how could Torvalds and coworkers possibly use "git"
> as a (distributed!) version control system tool for developing the
> Linux kernel?
... what? I made a very specific statement about Sage development.
Kernel development has nothing to do with it. In particular, I
*guarantee* you that the kernel devs do not rewrite published history in
their public tree, while we do so left and right, even when it's not
even necessary (i.e. when no patches even need to be backed out)!
In fact, here's `a quote`_ from the Linux kernel developer's guide:
if you rewrite history which other developers have pulled into their
repositories, you will make life much more difficult for those
developers. So a simple rule of thumb applies here: history which
has been exported to others should generally be seen as immutable
thereafter.
And we not only mutate history that has been exported to others, but
history that has been published as an official beta version of Sage!!
.. _a quote:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/development-process/7.AdvancedTopics;h=26dc3fa196e46fc9a1f8ef9f03e303c409e5b8b2;hb=HEAD#l80
To explain what I meant in more technical detail:
If we switch to git, commits made on an older dev release will not be
mergeable into the new dev release unless the new dev release is based
on (i.e. consists of a superset of the commits present in) the old dev
release.
(In the below, single lines indicate history private to a single
developer, and double lines indicate history published in our official
repository.)
How it would work if new dev releases were based on old dev releases
--------------------------------------------------------------------
1) A dev release is made, incorporating commits A and B.
o == A == B
^
1
2) A developer commits some changes on top of the release.
o == A == B -- X
^
1
3) Another release is made, incorporating commit C.
X
/
o == A == B == C
^ ^
1 2
4) The developer updates his changes with what has changed in the new
release. He then makes some fixes to make his code compatible with the
new release.
X -- M -- Y
/ /
o == A == B == C
^ ^
1 2
5) Another release is made, incorporating the developer's changes (X, M,
and Y), but first backing out the changes made in A, with commit D. This
release now incorporates X, M, Y, D, and E, on top of what was in the
previous release.
X == M === Y
// // \\
o == A == B == C == D == E
^ ^ ^
1 2 3
How it would work given current practices
-----------------------------------------
1) A release is made, incorporating commits A and B.
o == A == B
^
1
2) A developer commits some changes on top of the release.
o == A == B -- X
^
1
3) Another release is made, incorporating commit C but also duplicating
commits A and B. Notice that previously public, global commits have now
become private, local commits (the duplicated A and B).
A -- B -- X
/
o == A == B == C
^ ^
1 2
4) The developer updates his changes with what has changed in the new
release. He makes some fixes to make his code compatible with the new
release.
A -- B -- X -- M -- Y
/ /
o == A == B == C
^ ^
1 2
5) Another release is made, incorporating the developer's changes (X, M,
and Y), but first backing out the changes made in A, with commit D.
Pulling in the developer's changes also pulls in the two old copies of A
and B and one copy of C from the previous two dev releases. This release
now incorporates X, M, Y, D, E, old A, old B, old C, older A, and older
B on top of what was in the previous release.
A == B == X == M == Y
// // \\
/=== A == B == C \\
// \\
o == A == B == C == D ===== E
^ ^ ^
1 2 3
What is wrong with this picture:
* A and B now in the history in triplicate, and C in duplicate. This is
confusing and a waste of space, not to mention not indicative of what
actually happened (nobody actually independently committed A and B
three times or C twice).
* Even more importantly, while A was backed out by D, it is reintroduced
by the vestigial copies of A which came from the first and second dev
releases and are sitting in our developer's branch. This remains true
even if the third release simply omitted A, as Jeroen is currently
doing in such cases:
A == B == X == M == Y
// // \\
/=== A == B == C \\
// \\
o ======= B == C ========== E
^ ^ ^
1 2 3
To avoid this happening requires manual intervention (in particular,
rebasing) every time a new dev release is made. This is what I mean when
I say that the developer's changes are not mergeable unless we base new
development releases on old ones.
> To my understanding they have "lieutenants" responsible for different
> areas maintaining their own kernel tree each, and Linus Torvalds then
> pulls in the requested changes from each one. Or not. Or maybe later,
> partly, etc.pp. This must be a highly non-linear process! And git was
> *designed and created* (by Linus Torvalds himself!) to support this as
> easily and smoothly as possible.
Why do you think I have anything against non-linear development? On the
contrary, I welcome it! I invite you to look at the history of any
recent version of the Sage library. There has not been a single merge
commit to the Sage library since June 2010! This is entirely the product
of the current cherry-picking style of release management which treats
the version control system as a changelog rather than as a repository of
development history.
I am very surprised that you bring up the kernel development model as
somehow being an argument *against* what I have said. I can only
conclude that I was not sufficiently clear in explaining what I meant.
> Keshav, might there be some misunderstanding on your side?
Of course there very well might be, but if so, I am still unable see
it...
> Please do not hesitate to continue to ask questions, I'll try to
> answer them. But please be aware that I left university over a decade
> ago and am working since then in the software business in projects
> that are at least an order of magnitude bigger than Sage, daily using
> tools like cvs (which is quickly fading out), subversion, Perforce,
> git. So I might have grown quite some blind spots :-)
Of the four version control systems you list, git is fundamentally
different from the other three, being a *distributed* version control
system. git is, however, flexible enough to be used as a centralized VCS
like the others. Maybe your experience with git is in this vein?
> Honestly, it didn't occur to me that you could believe the above (from
> which it seems quite a good part of your motivation comes to open this
> thread), until you wrote it explicitly down ...
I hope I have now demonstrated the point sufficiently that you can take
it as just that - a point, rather than a "belief". But in any case,
please also note that my earlier message, and other messages in this
thread, had other points than this one - this is just the one Jeroen
happened to respond to.
Please tell me if anything else about what I said, in my previous
post(s) or this one, is insufficiently clear - I hope the diagrams are
of some help! And of course I welcome comments about the other points I
have made as well.
-Keshav
----
Join us in #sagemath on irc.freenode.net !
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
