Consideration for migrating from Subversion to Git

[Mike Swanson]

Hello there,

A couple of you have already seen me make this request in IRC, but I
will make a more formal one here.

I've noticed that ReactOS still uses the Subversion VCS, and while this
might have been a good choice when it was initially set up, in 2016, it
is a rather backwards and self-defeating method to develop software.
For users without write access to the repository, developing against it
means that SVN serves barely better than copying a whole directory just
to do a diff against it. Submitting patches means that they'll not be
split up into logical steps (commits), and increases the difficulty of
determining what a patch contains, or even making a sane commit message
for it.

In the modern DVCS world, this simply doesn't need to hold true. Each
clone of the repository is exactly as the name implies: it's a clone.
Users that want to hack away on the source are freer to do so, create
their own private branches, commit to all their heart's content, and
submit a pull request back to the project (don't think of GitHub as the
only example of pull requests: they come in many forms and can even
include "sending patches to a mailing list", which would still retain
better properties than the Subversion model).

I do urge to give consideration to moving development infrastructure to
Git[*]. It would greatly ease both developer burden, and especially
contributors' burden. It is, simply, what the modern world uses. :-)

Secondary tale: I'm aware of git.reactos.org and GitHub both having a
git-svn clone of the repository. These are "okay" for the most basic
glances of the repo, but be warned that git-svn is unmaintained,
extremely buggy, and should never be used for a serious migration. For
a migration, we'll use reposurgeon. Each repository is unique and the
problems cannot be fully automated away, sorry. Human intervention is
required to do these properly.

---

Now that I've talked about why, I'll note some observations about the
Subversion repository in its present state:

* Multiple logical projects exist in the namespace. At the very least,
each of the subdirectories under /trunk should be translated to
independent Git repositories. If there are even more historical ones
(I've only looked at HEAD), we should get a list of them.

* Old versions of RosBE are under /tags. Is RosBE maintained
elsewhere?

* A lot of old and new branches. If any of these are already merged
into trunk, it may be best to just discard their preservation. Per-
developer branches might work out best if each developer took
'ownership' of them with independent repository clones. An
infrastructure and organization like https://git.kernel.org/%C2%A0may be
worth looking into.

* Tagging conventions at least appear sane and logical, but they
should be named with more conventional names for Git, usually a bare
number or prefixed with v. For example, "0.3.17", "0.4.0", or
"v0.3.17", "v0.4.0" -- this is a pure policy decision, but with one-
project-per-repository, it keeps things looking clean.

* It is very large. Over a gigabyte as a live repository, 14GB as a
full stream dump. It will require a lot of memory to process and I'm
not sure my own system will handle that. It will also take a long time
to process and develop a migration -- the upper bound can be on the
order of months of work. Development in Subversion should not be halted
until the day the migration is being completed.

[*] Okay, it doesn't have to be Git. Hypothetically, any DVCS will do,
but only Mercurial has enough traction to be a viable alternative.

Thanks for listening,
  Mike

[Colin Finck]

Hi Mike,

So I was about to finish my ongoing server work in the next few days and
then push for a move to Git on the mailing lists. Thanks for spoiling
those plans! :)

I totally agree with all your raised points. I'm using Git every day at
work now, so do several of our developers. For some of us, ReactOS
remains the only project still using SVN.
While Git's usability under Windows has long been a problem (check
ros-dev from April 2009), TortoiseGit and GitHub have greatly simplified
things here.

I also got introduced into Git submodules recently. They're perfectly
suited for a large project like ReactOS that should be split up into
multiple smaller subprojects. Having several easily hackable
subprojects, and then having them on GitHub, gives us way more exposure
and probably more contributors.

So why hasn't this move happened earlier? Especially when some of our
developers are already actively using the git-svn mirror?
One reason is definitely trying to get a smooth transition done. You
already mentioned git-svn being buggy, and missing SVN branches are one
part of the problem. Reposurgeon looks interesting to do the right thing
here.
Given that I'm used to Git by now, I also wouldn't mind if we fix a
date, make SVN read-only on that date and do all development in Git from
then on. AFAIK, the same has also worked for the CVS to SVN transition.

But I could imagine that there are still developers tied to the SVN way
of doing things. We would at least need a detailed Wiki page explaining
some common SVN tasks and how they're now done in Git/TortoiseGit.
There has also been the idea of employing a two-way mirror solution like
SubGit for 6 months to ease the transition. While I'm not fully opposed
to that idea, I fear that some people won't even give up SVN after that
time. But even more important, this would prevent us from making use of
features like Git submodules.

Answering one of your other questions inline.

Am 24.02.2016 um 12:59 schrieb Mike Swanson:
> Old versions of RosBE are under /tags. Is RosBE maintained
>
> elsewhere?

We used to have everything in the one big "reactos" repository. First,
the website and media split off as the "web" and "press-media" repos,
then some tools followed as the "project-tools" repo. This one is also
where RosBE is now maintained.

When doing a proper transition to Git, all remnants of these
repositories should be removed from the history wherever possible.
Reposurgeon may be helpful here.

Cheers,

Colin

[Neal Gompa]

On Thu, Feb 25, 2016 at 1:41 AM, Colin Finck [e-mail] wrote:
> Hi Mike,
>
> So I was about to finish my ongoing server work in the next few days and
> then push for a move to Git on the mailing lists. Thanks for spoiling
> those plans! :)
>
> I totally agree with all your raised points. I'm using Git every day at
> work now, so do several of our developers. For some of us, ReactOS
> remains the only project still using SVN.
> While Git's usability under Windows has long been a problem (check
> ros-dev from April 2009), TortoiseGit and GitHub have greatly simplified
> things here.

The poor usability of Git on non-*nix platforms is one of the reasons
why I'm still a huge fan of Mercurial. Also, the SVN-like CLI workflow
means that's it's less disruptive than moving to Git. There's also a
fantastic guide on how to get started with Mercurial[0].

That being said, Mercurial and Git can interoperate with each other
fairly well. If you choose to have a Git server, then Mercurial can
talk to it through hg-git[1]. If you choose to have a Mercurial
server, then Git can talk to it through git-remote-hg[2].

However, Mercurial has better support for natively working in Windows,
and tends to handle the differences of platforms a whole lot better
than Git does. My experience with importing and contributing to SVN
based projects tends to be better with Mercurial than Git, simply
because the SVN data maps better in Mercurial.
> I also got introduced into Git submodules recently. They're perfectly
> suited for a large project like ReactOS that should be split up into
> multiple smaller subprojects. Having several easily hackable
> subprojects, and then having them on GitHub, gives us way more exposure
> and probably more contributors.

Mercurial supports subrepositories[3], which is a more advanced form
of Git's submodules. Mercurial's subrepositories do not have to be
Mercurial repositories, either. They can be SVN, Git, or any other
supportable source of repository information.

I'll admit to having some bias here against GitHub. I don't like it
very much, as I don't even find it very intuitive. There are a lot of
annoying shortcomings when it comes to how things are tracked and
recorded which annoy me. Between GitHub and BitBucket, I very much
prefer BitBucket. But generally speaking, I'm not much of a fan of
using proprietary software for software development. If we could avoid
it, that would be nice.

There are very nice FOSS tools out there for providing an excellent
development experience, such as Phabricator[4] and GitLab[5] for
self-hosted environments. If you really want to move to a Git based
hosted platform, GitLab.com offers free hosting[6], and there's also
BitBucket[7] for either Mercurial or Git.

[0]: http://hginit.com/
[1]: http://hg-git.github.io/
[2]: https://github.com/felipec/git-remote-hg
[3]: https://www.mercurial-scm.org/wiki/Subrepository
[4]: http://phabricator.org/
[5]: https://about.gitlab.com/features/
[6]: https://about.gitlab.com/gitlab-com/
[7]: https://bitbucket.org/
-- 
真実はいつも一つ！/ Always, there's only one truth!

[Oliver Schneider]

Hi all,

want to share some thoughts and experiences regarding a VCS migration.

On 2016-02-25 07:49, Neal Gompa wrote:
> The poor usability of Git on non-*nix platforms is one of the reasons
> why I'm still a huge fan of Mercurial. Also, the SVN-like CLI workflow
> means that's it's less disruptive than moving to Git. There's also a
> fantastic guide on how to get started with Mercurial[0].

First of all, I'm also a big fan of Mercurial for the exact same
reasons. And perhaps I'd also add that I find that Git often lives up to
its name (e.g. when I say `git <command> --help` I do *NOT* want to be
dropped into a man page but rather see a concise description of options).
> That being said, Mercurial and Git can interoperate with each other
> fairly well. If you choose to have a Git server, then Mercurial can
> talk to it through hg-git[1]. If you choose to have a Mercurial
> server, then Git can talk to it through git-remote-hg[2].

In all fairness hg-git broke for me _consistently_ in the past. I would
not consider it reliable or recommend it to anyone for anything but the
simplest/smallest of repositories. Sometimes it was the "connection"
between the two repos that broke or that some idiom of either side was
not understood by the other.
> However, Mercurial has better support for natively working in Windows,

SourceTree (by the makers of Bitbucket) provides a fairly good user
experience on Windows, but you often still need to drop to a command
prompt for certain advanced operations. But I've had this experience for
both Git and Mercurial.
> and tends to handle the differences of platforms a whole lot better
> than Git does. My experience with importing and contributing to SVN
> based projects tends to be better with Mercurial than Git,

Not sure what repos you have imported and by what means and how you
verified that the whole thing was a valid duplicate. However, I can tell
you from my experience that I have not found a single repo exceeding a
few dozen revisions that could be converted without losses using the
import tools provided by Hg _or_ Git communities.

A lot of prerequisites have to be met to allow for a migration to
produce a proper valid duplicate on the other version control system.
For SVN this means usually that the convention(!) of having top-level
folders trunk, branches and tags need to be true for the *whole*
revision range to be converted. So if you started without this
convention and then introduced it - bad luck. Same if you had certain
accidents on the SVN side. Same if you introduced another project as
top-level folder and later merged it.

All these "kinks" in the revision history are bound to throw off these
automated import tools. I do know that some of them employ heuristics to
"take care" of certain accidents. And of course one can opt to ignore
the visible warnings. But most of those instances would really have to
be reviewed by a human and require some kind of decision. So automatic
handling leads to loss of information.

Essentially it depends on how truthful you want your copy to be. If you
can do with something that "just works" -- and "Git from now on, but SVN
if you want to rebuild historic revisions" -- then you can probably use
the import tools provided by the Git community. If you need more, they
just won't cut it.
> simply because the SVN data maps better in Mercurial.

Sorry to say, but this is simply untrue. There are plenty of things in
Subversion that do not at all map to anything in either DVCS. Starting
with the concept of tags and branches as folders. Same for empty
folders. And in my conversions (about a dozen which I saw through to the
end) I have often ended up with cases where Git as the target VCS would
have been a better match than Mercurial. It really depends *if* you want
a high-quality conversion.

I have worked with reposurgeon for nearly three years and it's the only
comprehensive tool, I know of, to achieve lossless copies of a repo in
another version control system. It even comes with a companion tool to
verify the results and best of all it is a maintained FLOSS project
(hosted on a Gitlab instance, btw). I can help if you choose to go this
route to have a high-quality conversion using reposurgeon. And AFAIK ESR
(the author) himself will also happily help out FLOSS projects like
ReactOS when you run into trouble. He did the conversion of Emacs to
Git, btw.
> There are very nice FOSS tools out there for providing an excellent
> development experience, such as Phabricator[4] and GitLab[5] for
> self-hosted environments. If you really want to move to a Git based
> hosted platform, GitLab.com offers free hosting[6], and there's also
> BitBucket[7] for either Mercurial or Git.

Let me add Kallithea, although the aforementioned ones come with many
additional features. In particular Phabricator comes with a code review
platform which is also used by the LLVM project. Here's an example which
shows many of the features Phabricator offers:
http://reviews.llvm.org/D11532

Last but not least: I think it's also worthwhile to point out that the
LLVM projects are also still using SVN and they fare well with it. Those
wanting to use Git, can use a Git mirror and git-svn marks are used to
interoperate. So it is already possible to use Git without completely
migrating.

That said, take your time. Especially if you intend to take the SVN repo
down after migration.

// Oliver

PS: still it can be said that *if* you opt for a high-quality conversion
and want to migrate to another DVCS later on, the effort required will
be considerably lower than going from CVS or SVN _to_ any DVCS initially.

[Mike Swanson]

On Thu, 2016-02-25 at 09:45 +0000, Oliver Schneider wrote:
> I have worked with reposurgeon for nearly three years and it's the
> only
> comprehensive tool, I know of, to achieve lossless copies of a repo
> in
> another version control system. It even comes with a companion tool
> to
> verify the results and best of all it is a maintained FLOSS project
> (hosted on a Gitlab instance, btw). I can help if you choose to go
> this
> route to have a high-quality conversion using reposurgeon. And AFAIK
> ESR
> (the author) himself will also happily help out FLOSS projects like
> ReactOS when you run into trouble. He did the conversion of Emacs to
> Git, btw.

Yes, I've actually already mentioned to him that I might have to borrow
his Beast to pull off the task. Any help that can come with doing the
process should be greatly appreciated :-)

[Neal Gompa]

On Thu, Feb 25, 2016 at 1:26 PM, Mike Swanson
[e-mail] wrote:
> On Thu, 2016-02-25 at 09:45 +0000, Oliver Schneider wrote:
> > I have worked with reposurgeon for nearly three years and it's the
> > only
> > comprehensive tool, I know of, to achieve lossless copies of a repo
> > in
> > another version control system. It even comes with a companion tool
> > to
> > verify the results and best of all it is a maintained FLOSS project
> > (hosted on a Gitlab instance, btw). I can help if you choose to go
> > this
> > route to have a high-quality conversion using reposurgeon. And AFAIK
> > ESR
> > (the author) himself will also happily help out FLOSS projects like
> > ReactOS when you run into trouble. He did the conversion of Emacs to
> > Git, btw.
>
> Yes, I've actually already mentioned to him that I might have to borrow
> his Beast to pull off the task. Any help that can come with doing the
> process should be greatly appreciated :-)

I've been fiddling with locally migrating the ReactOS code from SVN to
Mercurial in my spare time for quite a while. I'd be happy to help
wherever I can to get ReactOS moved to Hg (or Git, I guess).
-- 
真実はいつも一つ！/ Always, there's only one truth!

[Ged Murphy]

Are we not just looking for a solution to a problem that doesn't really
exist? Is SVN stopping us from doing anything, or from changing to a better
way of working for our project style? The move from CVS to SVN was worth
doing, but is a move to git worth doing?

If you think we have a use for git submodules, would svn externals not do
what you want instead?

I like git (from my limited experience with it), but as the majority of our
developers work in a Windows environment, I'm not convinced it's worth
moving everyone to, especially when we already have the git mirror.

Although one real win for us in moving to github would be in moving our
repository off of our servers and onto git's cloud backed service.

Ged.

-----Original Message-----
From: Ros-dev [mailto:[e-mail]] On Behalf Of Colin Finck
Sent: 25 February 2016 06:42
To: [e-mail]
Subject: Re: [ros-dev] Consideration for migrating from Subversion to Git

Hi Mike,

So I was about to finish my ongoing server work in the next few days and
then push for a move to Git on the mailing lists. Thanks for spoiling those
plans! :)

I totally agree with all your raised points. I'm using Git every day at work
now, so do several of our developers. For some of us, ReactOS remains the
only project still using SVN.
While Git's usability under Windows has long been a problem (check ros-dev
from April 2009), TortoiseGit and GitHub have greatly simplified things
here.

I also got introduced into Git submodules recently. They're perfectly suited
for a large project like ReactOS that should be split up into multiple
smaller subprojects. Having several easily hackable subprojects, and then
having them on GitHub, gives us way more exposure and probably more
contributors.

So why hasn't this move happened earlier? Especially when some of our
developers are already actively using the git-svn mirror?
One reason is definitely trying to get a smooth transition done. You already
mentioned git-svn being buggy, and missing SVN branches are one part of the
problem. Reposurgeon looks interesting to do the right thing here.
Given that I'm used to Git by now, I also wouldn't mind if we fix a date,
make SVN read-only on that date and do all development in Git from then on.
AFAIK, the same has also worked for the CVS to SVN transition.

But I could imagine that there are still developers tied to the SVN way of
doing things. We would at least need a detailed Wiki page explaining some
common SVN tasks and how they're now done in Git/TortoiseGit.
There has also been the idea of employing a two-way mirror solution like
SubGit for 6 months to ease the transition. While I'm not fully opposed to
that idea, I fear that some people won't even give up SVN after that time.
But even more important, this would prevent us from making use of features
like Git submodules.

Answering one of your other questions inline.

Am 24.02.2016 um 12:59 schrieb Mike Swanson:
> Old versions of RosBE are under /tags. Is RosBE maintained
>
> elsewhere?

We used to have everything in the one big "reactos" repository. First, the
website and media split off as the "web" and "press-media" repos, then some
tools followed as the "project-tools" repo. This one is also where RosBE is
now maintained.

When doing a proper transition to Git, all remnants of these repositories
should be removed from the history wherever possible.
Reposurgeon may be helpful here.

Cheers,

Colin

[Neal Gompa]

On Thu, Feb 25, 2016 at 5:19 AM, Ged Murphy
[e-mail] wrote:
> Are we not just looking for a solution to a problem that doesn't really
> exist? Is SVN stopping us from doing anything, or from changing to a better
> way of working for our project style? The move from CVS to SVN was worth
> doing, but is a move to git worth doing?
>
> If you think we have a use for git submodules, would svn externals not do
> what you want instead?
>
> I like git (from my limited experience with it), but as the majority of our
> developers work in a Windows environment, I'm not convinced it's worth
> moving everyone to, especially when we already have the git mirror.
>
> Although one real win for us in moving to github would be in moving our
> repository off of our servers and onto git's cloud backed service.
>
> Ged.

If your goal is to move it all off your own servers, you could just go
for BitBucket and move to cloud JIRA and tie the two together. Over
there, you can use either Mercurial or Git. BitBucket organizations
can have projects, which have repositories, and that multi-level
organization (unique to BitBucket) would allow for some interesting
opportunities in enabling people to work on different aspects of
ReactOS (application software, core OS code, build stuff, etc.).
-- 
真実はいつも一つ！/ Always, there's only one truth!

[David Quintana (gigaherz)]

I think the real goal with moving to a platform such as github is reducing
the entry barriers for new contributors. As it has been mentioned already,
almost all projects who moved from SVN with "send patches" contribution
system, to Git/Hg with Pull Requests have got non-negligible growth in
contributions.

The reason I'd agree with using github as a target, is simply their svn
bridge that allows developers who want to avoid git to still commit to a
fork with SVN and be able to send pull requests afterward.

I have no experience with Hg beyond cloning one or two repositories that I
needed code from (years ago), so I don't know how they compare
feature-wise, or what the best GUI interfaces are for it. I do however know
that without tortoiseGit, I'd probably still be pushing to remain on SVN.

And for anyone reading this who knows SVN but hasn't really learned to use
DVCSs yet, there is one key concept that makes all the difference for
someone used to SVN to understand how git works: the fact that the
operations you normally do with SVN are THE SAME on git, they just work on
the local repository clone, instead of the server:

- Svn checkout -> git checkout from local clone
   - Svn commit -> git commit to local clone
   - Svn diff -> git diff from local clone
   - ...

Git simply has a separate set of concepts for interacting with remotes:
Clone, Pull, Fetch, Rebase, Push, Force-push, Squash, etc. The whole thing
becomes much less confusing if you get that idea.

On 25 February 2016 at 11:32, Neal Gompa [e-mail] wrote:
> On Thu, Feb 25, 2016 at 5:19 AM, Ged Murphy
> [e-mail] wrote:
> > Are we not just looking for a solution to a problem that doesn't really
> > exist? Is SVN stopping us from doing anything, or from changing to a
>
> better
> > way of working for our project style? The move from CVS to SVN was worth
> > doing, but is a move to git worth doing?
> >
> > If you think we have a use for git submodules, would svn externals not do
> > what you want instead?
> >
> > I like git (from my limited experience with it), but as the majority of
>
> our
> > developers work in a Windows environment, I'm not convinced it's worth
> > moving everyone to, especially when we already have the git mirror.
> >
> > Although one real win for us in moving to github would be in moving our
> > repository off of our servers and onto git's cloud backed service.
> >
> > Ged.
>
> If your goal is to move it all off your own servers, you could just go
> for BitBucket and move to cloud JIRA and tie the two together. Over
> there, you can use either Mercurial or Git. BitBucket organizations
> can have projects, which have repositories, and that multi-level
> organization (unique to BitBucket) would allow for some interesting
> opportunities in enabling people to work on different aspects of
> ReactOS (application software, core OS code, build stuff, etc.).
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

> I think the real goal with moving to a platform such as github is reducing
> the entry barriers for new contributors. As it has been mentioned already,
> almost all projects who moved from SVN with "send patches" contribution
> system, to Git/Hg with Pull Requests have got non-negligible growth in
> contributions.

I'm confused, maybe it's your use of a double negative (non-negligible), but that sounds contradictory?
Are you saying that projects that have moved from SVN to git have had no growth or good growth in contributions?

Ged.

[Ged Murphy]

Okay ignore me, we cleared it up in IRC. David means significant, I've just never heard ........ nevermind ......

If moving to git will increase the likelihood of patches from outside the team, then that in itself is a good enough reason to move IMO.

-----Original Message-----
From: Ged Murphy [mailto:[e-mail]] 
Sent: 25 February 2016 11:26
To: 'ReactOS Development List' [e-mail]
Subject: RE: [ros-dev] Consideration for migrating from Subversion to Git
> I think the real goal with moving to a platform such as github is 
> reducing the entry barriers for new contributors. As it has been 
> mentioned already, almost all projects who moved from SVN with "send 
> patches" contribution system, to Git/Hg with Pull Requests have got 
> non-negligible growth in contributions.

I'm confused, maybe it's your use of a double negative (non-negligible), but that sounds contradictory?
Are you saying that projects that have moved from SVN to git have had no growth or good growth in contributions?

Ged.

[David Quintana (gigaherz)]

Sorry about that. I guess I have read a lot of technical papers ;P

On 25 February 2016 at 12:47, Ged Murphy [e-mail]
wrote:
> Okay ignore me, we cleared it up in IRC. David means significant, I've
> just never heard ........ nevermind ......
>
> If moving to git will increase the likelihood of patches from outside the
> team, then that in itself is a good enough reason to move IMO.
>
> -----Original Message-----
> From: Ged Murphy [mailto:[e-mail]]
> Sent: 25 February 2016 11:26
> To: 'ReactOS Development List' [e-mail]
> Subject: RE: [ros-dev] Consideration for migrating from Subversion to Git
> > I think the real goal with moving to a platform such as github is
> > reducing the entry barriers for new contributors. As it has been
> > mentioned already, almost all projects who moved from SVN with "send
> > patches" contribution system, to Git/Hg with Pull Requests have got
> > non-negligible growth in contributions.
>
> I'm confused, maybe it's your use of a double negative (non-negligible),
> but that sounds contradictory?
> Are you saying that projects that have moved from SVN to git have had no
> growth or good growth in contributions?
>
> Ged.
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Zachary Gorden]

I would personally be on the side arguing AGAINST any sort of
migration to git as the primary repository. We have a mirror that
already exists, I see no reason why that is insufficient.

Whether contributions are provided as a single patch versus multiple
'commits' is, in my opinion, a matter of personal preference and one
is not inherently superior to the other. SVN is just as capable of
supporting branches that keep track of changes via commits, but the
times wherein I've used branches for development when I merge back to
trunk I do a single combined commit with all the changes rolled into
one, which ignores all of the previous development commits done to the
branch. I have never found reason to want all the extraneous commits,
their history is preserved in the tagged branch.

Git also remains extremely cumbersome in the one point where one would
think its developers would have gone out of their way to make the
operation as seamless and unneeding of direct intervention as
possible, the actual process of combining your changes with that of
other people. The fact that it does not automatically track changes of
files ALREADY part of the repository has never made sense to me, why
wouldn't I want any local changes I've made be merged cleanly with
whatever upstream changes are pulled down? Though I've always felt
that was more a cop out to try to minimize the burden on git's
remarkably crappy diff/merge support in the first place. How does it
mess up changes that are in two completely separate places in the same
file in this day and age is beyond me when SVN doesn't have this
problem.

Poor performance/usability on Windows is not just a matter of tooling.
Due to the size that the git history can grow to, it literally can end
up stalling out when doing operations. A place where I previously
worked resorted to trimming history. Unless the git developers are
willing to actually go into their internals and change how they do
file I/O to use dedicated Windows functions (there are hard limits to
the standard C file i/o functions on Windows) no amount of tooling
around the edges is going to fix that problem. Combined with the
constant extraneous merges generated because git 'insists' on merging
instead of automatically attempting to rebase when someone else gets
in a commit before you, we have a fundamental problem here.

I've used git, fairly extensively at that. I've generally found it to
be a much poorer user experience than SVN, especially in light of the
fact that I don't care about a lot of its 'features.' In fact the only
feature that it has that is a genuine feature and is not just a more
convoluted way of doing the same thing with SVN is local branches.
That can be useful, but that's achievable with the git mirror and
doesn't require those of us who do not want to use git to have to
suffer through its clunkiness. And when git due to its nature can
result in a lot of situations where it's faster to just nuke your
checkout and reclone instead of trying to untangle whatever snarl it
got its local history into, I would argue it's not doing a very good
job as a revision control system.

On Thu, Feb 25, 2016 at 6:55 AM, David Quintana (gigaherz)
[e-mail] wrote:
> Sorry about that. I guess I have read a lot of technical papers ;P
>
> On 25 February 2016 at 12:47, Ged Murphy [e-mail]
> wrote:
> > Okay ignore me, we cleared it up in IRC. David means significant, I've
> > just never heard ........ nevermind ......
> >
> > If moving to git will increase the likelihood of patches from outside the
> > team, then that in itself is a good enough reason to move IMO.
> >
> > -----Original Message-----
> > From: Ged Murphy [mailto:[e-mail]]
> > Sent: 25 February 2016 11:26
> > To: 'ReactOS Development List' [e-mail]
> > Subject: RE: [ros-dev] Consideration for migrating from Subversion to Git
> > > I think the real goal with moving to a platform such as github is
> > > reducing the entry barriers for new contributors. As it has been
> > > mentioned already, almost all projects who moved from SVN with "send
> > > patches" contribution system, to Git/Hg with Pull Requests have got
> > > non-negligible growth in contributions.
> >
> > I'm confused, maybe it's your use of a double negative (non-negligible),
> > but that sounds contradictory?
> > Are you saying that projects that have moved from SVN to git have had no
> > growth or good growth in contributions?
> >
> > Ged.
> >
> > Ros-dev mailing list
> > [e-mail]
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Neal Gompa]

On Thu, Feb 25, 2016 at 5:54 AM, David Quintana (gigaherz)
[e-mail] wrote:
> I think the real goal with moving to a platform such as github is reducing
> the entry barriers for new contributors. As it has been mentioned already,
> almost all projects who moved from SVN with "send patches" contribution
> system, to Git/Hg with Pull Requests have got non-negligible growth in
> contributions.
>
> The reason I'd agree with using github as a target, is simply their svn
> bridge that allows developers who want to avoid git to still commit to a
> fork with SVN and be able to send pull requests afterward.
>
> I have no experience with Hg beyond cloning one or two repositories that I
> needed code from (years ago), so I don't know how they compare feature-wise,
> or what the best GUI interfaces are for it. I do however know that without
> tortoiseGit, I'd probably still be pushing to remain on SVN.

There are several excellent graphical interfaces for Mercurial. The
most popular one is TortoiseHg[0], which provide desktop shell
integration like TortoiseSVN and TortoiseGit do. For those who don't
care for shell integration, but want a good graphical workflow,
there's Atlassian SourceTree[1] (which also works for Git).
Smart(Git/Hg)[2] is a lesser-known alternative to SourceTree.

On the IDE integration front, Mercurial support is integrated into
CLion[3], NetBeans[4], and two actively maintained Visual Studio
source control extensions[5][6].

Other frontends and integration extensions are listed on the Mercurial site[7].
> And for anyone reading this who knows SVN but hasn't really learned to use
> DVCSs yet, there is one key concept that makes all the difference for
> someone used to SVN to understand how git works: the fact that the
> operations you normally do with SVN are THE SAME on git, they just work on
> the local repository clone, instead of the server:
>
> Svn checkout -> git checkout from local clone
> Svn commit -> git commit to local clone
> Svn diff -> git diff from local clone
> ...
>
> Git simply has a separate set of concepts for interacting with remotes:
> Clone, Pull, Fetch, Rebase, Push, Force-push, Squash, etc. The whole thing
> becomes much less confusing if you get that idea.

And this is all true for Mercurial, as well. Virtually all DVCSes work
in this manner (though the syntax and semantics might slightly
differ).

[0]: http://tortoisehg.bitbucket.org/
[1]: https://www.sourcetreeapp.com/
[2]: http://www.syntevo.com/smartgit/
[3]: https://www.jetbrains.com/clion/help/using-mercurial-integration.html
[4]: http://wiki.netbeans.org/MercurialVersionControl
[5]: http://www.newsupaplex.pp.ru/hgscc_news_eng.html
[6]: http://visualhg.codeplex.com/
[7]: https://www.mercurial-scm.org/wiki/OtherTools
-- 
真実はいつも一つ！/ Always, there's only one truth!

[Aleksey Bragin]

I was already discussing this a little bit with Colin.

I must say I use (Tortoise)Git for all my non-FOSS projects, and I use 
GitHub for the ring3k project I am developing now with a student 
https://github.com/bragin/ring3k

Conclusion from my experience is so far:
- There is no bottleneck in VCS vs DVCS in ReactOS (considering amount 
of active devs we have now, and amount of active development happening 
right now)
- GitHub automagically does not attract devs (We are developing Ring3k 
for a few months without any advertisiment, and "noone cares"). Oh well, 
I got a few private messages regarding development but that's it.
- For private projects GIT rocks.

So, my answer is: no, there is no need to migrate to DVCS for ReactOS now.

Regards,
Aleksey Bragin
P.S. Flame about which VCS is better may go on forever :-)

On 25.02.2016 13:19, Ged Murphy wrote:
> Are we not just looking for a solution to a problem that doesn't really
> exist? Is SVN stopping us from doing anything, or from changing to a better
> way of working for our project style? The move from CVS to SVN was worth
> doing, but is a move to git worth doing?
>
> If you think we have a use for git submodules, would svn externals not do
> what you want instead?
>
> I like git (from my limited experience with it), but as the majority of our
> developers work in a Windows environment, I'm not convinced it's worth
> moving everyone to, especially when we already have the git mirror.
>
> Although one real win for us in moving to github would be in moving our
> repository off of our servers and onto git's cloud backed service.
>
> Ged.
>
> -----Original Message-----
> From: Ros-dev [mailto:[e-mail]] On Behalf Of Colin Finck
> Sent: 25 February 2016 06:42
> To: [e-mail]
> Subject: Re: [ros-dev] Consideration for migrating from Subversion to Git
>
> Hi Mike,
>
> So I was about to finish my ongoing server work in the next few days and
> then push for a move to Git on the mailing lists. Thanks for spoiling those
> plans! :)
>
> I totally agree with all your raised points. I'm using Git every day at work
> now, so do several of our developers. For some of us, ReactOS remains the
> only project still using SVN.
> While Git's usability under Windows has long been a problem (check ros-dev
> from April 2009), TortoiseGit and GitHub have greatly simplified things
> here.
>
> I also got introduced into Git submodules recently. They're perfectly suited
> for a large project like ReactOS that should be split up into multiple
> smaller subprojects. Having several easily hackable subprojects, and then
> having them on GitHub, gives us way more exposure and probably more
> contributors.
>
> So why hasn't this move happened earlier? Especially when some of our
> developers are already actively using the git-svn mirror?
> One reason is definitely trying to get a smooth transition done. You already
> mentioned git-svn being buggy, and missing SVN branches are one part of the
> problem. Reposurgeon looks interesting to do the right thing here.
> Given that I'm used to Git by now, I also wouldn't mind if we fix a date,
> make SVN read-only on that date and do all development in Git from then on.
> AFAIK, the same has also worked for the CVS to SVN transition.
>
> But I could imagine that there are still developers tied to the SVN way of
> doing things. We would at least need a detailed Wiki page explaining some
> common SVN tasks and how they're now done in Git/TortoiseGit.
> There has also been the idea of employing a two-way mirror solution like
> SubGit for 6 months to ease the transition. While I'm not fully opposed to
> that idea, I fear that some people won't even give up SVN after that time.
> But even more important, this would prevent us from making use of features
> like Git submodules.
>
> Answering one of your other questions inline.
>
> Am 24.02.2016 um 12:59 schrieb Mike Swanson:
> > Old versions of RosBE are under /tags. Is RosBE maintained
> >
> > elsewhere?
>
> We used to have everything in the one big "reactos" repository. First, the
> website and media split off as the "web" and "press-media" repos, then some
> tools followed as the "project-tools" repo. This one is also where RosBE is
> now maintained.
>
> When doing a proper transition to Git, all remnants of these repositories
> should be removed from the history wherever possible.
> Reposurgeon may be helpful here.
>
> Cheers,
>
> Colin