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/šmay 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

,

_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev