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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
