[LLVMdev] svn mirror git?

[David Tweed]

Hi,

This probably isn't significant evidence about using svn as the
authoritative revision control system for llvm but more just to point out
that the svn users tend to consider that the only thing one would use
revision control for is the mainstream development history tracking.

I'll note that I during working ("development" but also bug-fixing and
experimentation) since the advent of git I've been using revision storage
much, much more extensively than before. For instance, I've got a private
branch with a cron job takes a commit of the working tree every 10 minutes
(even if it isn't in a compilable state) cleaning them out after every day
and likewise one that takes a commit every hour. This means that if I
suddenly see a weird behaviour change in something I'm working on I can step
back through revisions until I find one which compiles and has the old
behaviour, then diff the two to find stuff to investiage rather than have to
think "what did I change recently". Likewise I'm into the habit of creating
throwaway merge branches with mainline when doing development in order to
check if there's conflicts. And it provides a nice way to synchronise
"personal" development between machines which can't see a common filesystem.
Currently I do all this using git (with the external feed from git-svn) and
then create "considered" patches against svn once I've figured stuff out.

Now none of this has any effect on the "proper world-viewable
linearised-history source repository". What's nice about git (and I suppose
hg, although I've not used that as intensively) is that both these internal
activities and the longer-term, externally visible pieces of development is
that they're done with the same tools and in the same personal repository
(with bits that don't get transmitted to external repos). On the other hand
SVN is deliberately designed to work well as "the central revision control
history" of the project but not to be the tool for doing anything else.
Which is fine, but it is a particular choice of what's within its remit
rather than any fundamental constraint.

Couple of additional comments inline.

On Thu, Nov 15, 2012 at 6:59 PM,  <dag at cray.com> wrote:
> David Chisnall <David.Chisnall at cl.cam.ac.uk> writes:
>
>> On 15 Nov 2012, at 12:31, <dag at cray.com> wrote:
>>
>>> - Easier third-party merging.  Merging via git merge/rebase is MUCH
>>>  simpler than merging a tarball from svn.  I know the llvm leaders
>>>  don't seem to care about this but it is a real issue for many users.
>>>
>>> - Ease of fork/merge.  git makes it easy to experiment with long-lived
>>>  development branches.  svn forces all development into trunk which
>>>  limits experimentation and innovation.
>>
>> Neither of these are true.  There is nothing stopping people from
>> working in branches in svn
>
> Yes there is.  I have asked about it many times and have always been
> refused.

Actually, the fact that (if you're using svn to store information about your
branch) this branch is getting stored on the central server can be
off-putting, particularly if you're storing a lot of stuff you plan to later
delete once you've figured out the right way to do things.

>> and merging from branches is easy.
>
> That is absolutely not true for any significant merge operation.
>
>> The advantage with git is that it's very easy to have your fork
>> somewhere where no one else sees it and your changes get lost and
>> forgotten.
>
> Actually that's true today with svn.  We have a ton of changes here we'd
> like to submit but the process is really painful.
>
>> Your point about small incremental commits is also untrue.  svn
>> encourages small incremental commits and, more importantly, encourages
>> small incremental pushes upstream.
>
> An svn commit is an expensive operation.  A git commit is a cheap
> operation.  That's why I'm referring to.  Development inertia under svn
> tends to steer the developer toward making larger changes before
> committing.  With git committing becomes an almost unnoticed part of the
> process.  At least that's been my experience.
>
>> This is something we want to encourage: we don't want to make it
>> easier for people to have private forks than it is to push them
>> upstream.
>
> There is value in those private forks.  As I said, having places to
> experiment is important.

Note that there's a tendency to call everything a "fork" even if it's really
just "thinking/experimentation", but the word "fork" conveys in the readers
mind something deliberate, thought-out and long-term.

Regards,
Dave