[ros-dev] Consideration for migrating from Subversion to Git
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
[ros-dev] Consideration for migrating from Subversion to Git
On Thu, Feb 25, 2016 at 5:54 AM, David Quintana (gigaherz) 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. I don't know... Speaking about "the entry barriers for new contributors", this is contributing now: 1. svn checkout svn://svn.reactos.org/reactos/trunk/reactos 2. // make changes 3. svn diff > patch_for_JIRA_issue compare it with "Git/Hg with Pull Requests": 1. Create/Log in to your GitHub account 2. Go to the page for the code respository you want to contribute to (the “upstream”) 3. “Fork” the repository (this creates a clone to your GitHub account) 4. Create a local clone of your fork with git clone 5. Create a local branch for your changes 6. Make your changes and commit them to your local branch with git commit, ensuring to include a descriptive commit message 7. Push the branch to your GitHub fork using git push 8. Go to the page for the upstream repository go to the pull requests tab 9. Click the “New Pull Request” Button 10. Select the branch you want to submit, and write a summary of what your change explaining what it is intended to do and how it is implemented which is the process for "Raising a Pull Request" described in here: http://oss-watch.ac.uk/resources/pullrequest (the preferred source chosed by Google search for explaining to me what a "pull request" is). Ignoring the fact that new ReactOS contributions will have as prerequisite the signing up for a (commercial) third party service, GitHub may appear a good move for those familiar with GitHub intrinsic knowledge, but it doesn't to for the rest of us. I know that Amine Khaldi offered (on IRC, on #reactos-dev) to help to "resort to manually relaying to GH" "only if someone doesn't want to" sign up, but this will be counterproductive (who wants to be a burden and to abuse in such a way precious developer's time?) and will most likely prevent many not-so-motivated (but potentially precious) contributions outside this cherished GitHub community. ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Consideration for migrating from Subversion to Git
We have RO mirrors forgit https://git.reactos.org/and github https://github.com/reactos/reactos Also I vote for JIRA upgrade to 7.1 version (from 6.0) which implemets some of git\github features even been used over SVN 25.02.2016, 00:01, "Mike Swanson" :Hello there,A couple of you have already seen me make this request in IRC, but Iwill make a more formal one here.I've noticed that ReactOS still uses the Subversion VCS, and while thismight have been a good choice when it was initially set up, in 2016, itis a rather backwards and self-defeating method to develop software.For users without write access to the repository, developing against itmeans that SVN serves barely better than copying a whole directory justto do a diff against it. Submitting patches means that they'll not besplit up into logical steps (commits), and increases the difficulty ofdetermining what a patch contains, or even making a sane commit messagefor it.In the modern DVCS world, this simply doesn't need to hold true. Eachclone 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, createtheir own private branches, commit to all their heart's content, andsubmit a pull request back to the project (don't think of GitHub as theonly example of pull requests: they come in many forms and can eveninclude "sending patches to a mailing list", which would still retainbetter properties than the Subversion model).I do urge to give consideration to moving development infrastructure toGit[*]. It would greatly ease both developer burden, and especiallycontributors' burden. It is, simply, what the modern world uses. :-)Secondary tale: I'm aware of git.reactos.org and GitHub both having agit-svn clone of the repository. These are "okay" for the most basicglances of the repo, but be warned that git-svn is unmaintained,extremely buggy, and should never be used for a serious migration. Fora migration, we'll use reposurgeon. Each repository is unique and theproblems cannot be fully automated away, sorry. Human intervention isrequired to do these properly.---Now that I've talked about why, I'll note some observations about theSubversion 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 toindependent 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 maintainedelsewhere? * A lot of old and new branches. If any of these are already mergedinto 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. Aninfrastructure and organization like https://git.kernel.org/ may beworth looking into. * Tagging conventions at least appear sane and logical, but theyshould be named with more conventional names for Git, usually a barenumber 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 afull stream dump. It will require a lot of memory to process and I'mnot sure my own system will handle that. It will also take a long timeto process and develop a migration -- the upper bound can be on theorder of months of work. Development in Subversion should not be halteduntil 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 listRos-dev@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev --Best regards,Alexander Rechitskiy ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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 smime.p7s Description: S/MIME Cryptographic Signature ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Consideration for migrating from Subversion to Git
On Thu, Feb 25, 2016 at 1:41 AM, Colin Finck 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! ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Consideration for migrating from Subversion to Git
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 --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/
Re: [ros-dev] Consideration for migrating from Subversion to Git
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:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck Sent: 25 February 2016 06:42 To: ros-dev@reactos.org 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Consideration for migrating from Subversion to Git
On Thu, Feb 25, 2016 at 5:19 AM, 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. > 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 Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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. 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 wrote: > On Thu, Feb 25, 2016 at 5:19 AM, 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. > > > > 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 > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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 Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Consideration for migrating from Subversion to Git
On Thu, Feb 25, 2016 at 5:54 AM, David Quintana (gigaherz) 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! ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Consideration for migrating from Subversion to Git
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:gedmurphy.mailli...@gmail.com] Sent: 25 February 2016 11:26 To: 'ReactOS Development List' 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 Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Consideration for migrating from Subversion to Git
Sorry about that. I guess I have read a lot of technical papers ;P On 25 February 2016 at 12:47, Ged Murphy 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:gedmurphy.mailli...@gmail.com] > Sent: 25 February 2016 11:26 > To: 'ReactOS Development List' > 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 > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Consideration for migrating from Subversion to Git
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) wrote: > Sorry about that. I guess I have read a lot of technical papers ;P > > On 25 February 2016 at 12:47, Ged Murphy > 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:gedmurphy.mailli...@gmail.com] >> Sent: 25 February 2016 11:26 >> To: 'ReactOS Development List' >> 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 >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > ___ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Consideration for migrating from Subversion to Git
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:ros-dev-boun...@reactos.org] On Behalf Of Colin Finck Sent: 25 February 2016 06:42 To: ros-dev@reactos.org 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 ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Re: [ros-dev] Consideration for migrating from Subversion to Git
On Thu, 2016-02-25 at 09:45 +, 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 :-) 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
Re: [ros-dev] Consideration for migrating from Subversion to Git
On Thu, Feb 25, 2016 at 1:26 PM, Mike Swanson wrote: > On Thu, 2016-02-25 at 09:45 +, 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! ___ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
