Moving from SVN to Mercurial: personal experience
To work with Mercurial under Windows, you only need TortoiseHG . Writing your own plugins for Mercurial will not work, but most developers don't seem to write them. In any case, I occasionally write only scripts for automation. If you have Visual Studio, you can use a beautiful plugin .
We will leave local repositories, teams on a piece of paper and others for students and laboratory works, which are for the whole Internet cars. Since Mercurial’s only benefit for mere mortals is to work offline, this should be used. That is, we are creating the main repository online: Mercurial now supports Microsoft and Google (that's amazing!), So apologists can choose their favorite corporation without suffering. But with one nuance, MS does not have a Russian in the comments to the commits.
Just want to agree. I am a supporter of Microsoft’s development policy not only in terms of tools, but also in terms of ways. Therefore, the problems of SVN (100 people changed 100 lines in one file and in the midst of this holiday someone renamed it) never touched my company and Subversion arranges for 90%. Three to four programmers are working on the project; a single programmer solves a separate task or a series of tasks for one component. There is no conflict between the coder and the coder, because they are editing different files (because the code is behind), and they can always agree on global changes to the joint work front. You just need to design weak links between components.
Here are the remaining 10% to happiness (offline) and will be implemented by means of Mercurial.
')
Choosing from hosting sites I stopped at Bitbucket . Firstly, it provides free hosting for small private repositories and paid for large ones. In my opinion, this is a competent approach - as long as you are few and you don’t want to publish your code, you still don’t get money from you, you will find some workaround. Secondly, he understands, accepts and shows Russian comments, unlike Codeplex. Thirdly, the Google code looks more modern, works faster, IE9 doesn’t constantly drop, and is generally better done, but it has a limit of 2 gigabytes per repository.
2 gigabytes per repository is a lot, we have 600 megabytes in SVN with 200 megabytes of pure content. It is unlikely that in the next five years we will reach the level. Therefore, if you have no desire to close the code and the restriction of 2 gigabytes doesn’t scare, you can be hosted by Google, of all three hosts I have reviewed, it is the most polished. Moreover, moving to another hosting is a maximum of 1 day of linear time and an hour or two spent.
This is a rather interesting topic, since in the Russian version of the description of Mercurial and in many places on the Internet they write that nested repositories are impossible, not for that Mercurial, allegedly, was made. This opportunity actually appeared a long time ago.
It works, relative to svn: externals, correctly, but with nuances. The correctness is that the used revision is stored for the nested repository and this revision is supported automatically. This means that when you do clone, you will not have the latest version of the nested repository, but the one with which your main project works. This is nuance number one. Plus it is that you always have the version of the embedded project that your main project works with (even if you switch to the old revision to make corrections to the previous version of your project), and the small disadvantage is that the nested project needs to be updated manually ( update its revision).
Support for correct revision is implemented as follows: when you commit to a nested repository, the nested repository revision is automatically clicked at the main repository. Accordingly, in order for everyone to see your update, this clicked revision of the nested repository must be registered, it is stored in the ".hgsubstate" file.
The second nuance can come up when you want to transfer changes from your repository directly to someone. To do this with a nuance, you need to make changes to the nested project, commit them, commit changes to the revision (these two committees can be combined into one, HG allows) and make changes to the main project and also commit them. Now pull changes from your repository to others and get “abort: unknown revision '...'!”. This happens for obvious reasons - a new revision of the attached project remains in your repository.
The third nuance is the decoupling from the default main repository of the nested project. A simple option is to fix the file with its address (.hgsub) and write anything there (for example, the path on your local filesystem), but this is unscientific. Scientifically, if you use the [subpaths] section in .hgrc.
When you push changes to the main repository of the main project, the changes and the nested project are automatically pushed. It's good. My advice is to avoid the materialization of beautiful intricate drawings that draw in all the guides for “beginners” (about the possibility of pushing commits across distant land).
I began to familiarize myself with distributed systems using the example of Git, simply because I occasionally come across references to it. I didn’t find the sane GUI-client and they all say with one voice, only Mercurial has it, and its name is TortoiseHG. In the process of casual mentioning in a conversation with a friend, it turned out that his voice was also on the side of Mercurial. And the other two, too.
Loved the landmark on antiquities. For example, I found only in minted comments that importing the repository from SVN to Mercurial does not require dancing, as described in the trillion manuals (including the combat wiki ), guides, etc. - hg convert svn ... works directly from the TortoiseHG box. And it did not happen yesterday, it works for several years.
The same landmark on antiquities and spherical horses when compared with SVN. Oh, how sad it is that the multi-week brunches without a merge with a trunking then sweep with conflicts! Oh, how sad it is that we can not commit code that does not work, because we Krivorukov developers do not do brunches! But the beautiful Mercurial / Git smogzit everything very smoothly, because la la la la and brunches are obtained automatically with cloning. First, all comparisons are made for some reason with the version of Subversion somewhere 1.2-1.4, before major changes in 1.5 and with 1.7 on the nose. Secondly, if a few weeks do not merge with the dev branch, then you will miss the changes that are not related to the merge - the signatures of the methods will change, the interfaces and so on, everything will be fine, but it will not work.
In the opposite direction are the same horses, only the version of Mercurial is taken 0.9. You can't, you see, create nested repositories. The Russian translation still says that Mercurial was not created for this. In the English version, there are already links to Subrepository , but only a few years have passed, in March 2010, even support for the embedded Subversion appeared.
We will leave local repositories, teams on a piece of paper and others for students and laboratory works, which are for the whole Internet cars. Since Mercurial’s only benefit for mere mortals is to work offline, this should be used. That is, we are creating the main repository online: Mercurial now supports Microsoft and Google (that's amazing!), So apologists can choose their favorite corporation without suffering. But with one nuance, MS does not have a Russian in the comments to the commits.
Just want to agree. I am a supporter of Microsoft’s development policy not only in terms of tools, but also in terms of ways. Therefore, the problems of SVN (100 people changed 100 lines in one file and in the midst of this holiday someone renamed it) never touched my company and Subversion arranges for 90%. Three to four programmers are working on the project; a single programmer solves a separate task or a series of tasks for one component. There is no conflict between the coder and the coder, because they are editing different files (because the code is behind), and they can always agree on global changes to the joint work front. You just need to design weak links between components.
Here are the remaining 10% to happiness (offline) and will be implemented by means of Mercurial.
')
Hosting
Choosing from hosting sites I stopped at Bitbucket . Firstly, it provides free hosting for small private repositories and paid for large ones. In my opinion, this is a competent approach - as long as you are few and you don’t want to publish your code, you still don’t get money from you, you will find some workaround. Secondly, he understands, accepts and shows Russian comments, unlike Codeplex. Thirdly, the Google code looks more modern, works faster, IE9 doesn’t constantly drop, and is generally better done, but it has a limit of 2 gigabytes per repository.
2 gigabytes per repository is a lot, we have 600 megabytes in SVN with 200 megabytes of pure content. It is unlikely that in the next five years we will reach the level. Therefore, if you have no desire to close the code and the restriction of 2 gigabytes doesn’t scare, you can be hosted by Google, of all three hosts I have reviewed, it is the most polished. Moreover, moving to another hosting is a maximum of 1 day of linear time and an hour or two spent.
Nested repositories
This is a rather interesting topic, since in the Russian version of the description of Mercurial and in many places on the Internet they write that nested repositories are impossible, not for that Mercurial, allegedly, was made. This opportunity actually appeared a long time ago.
It works, relative to svn: externals, correctly, but with nuances. The correctness is that the used revision is stored for the nested repository and this revision is supported automatically. This means that when you do clone, you will not have the latest version of the nested repository, but the one with which your main project works. This is nuance number one. Plus it is that you always have the version of the embedded project that your main project works with (even if you switch to the old revision to make corrections to the previous version of your project), and the small disadvantage is that the nested project needs to be updated manually ( update its revision).
Support for correct revision is implemented as follows: when you commit to a nested repository, the nested repository revision is automatically clicked at the main repository. Accordingly, in order for everyone to see your update, this clicked revision of the nested repository must be registered, it is stored in the ".hgsubstate" file.
The second nuance can come up when you want to transfer changes from your repository directly to someone. To do this with a nuance, you need to make changes to the nested project, commit them, commit changes to the revision (these two committees can be combined into one, HG allows) and make changes to the main project and also commit them. Now pull changes from your repository to others and get “abort: unknown revision '...'!”. This happens for obvious reasons - a new revision of the attached project remains in your repository.
The third nuance is the decoupling from the default main repository of the nested project. A simple option is to fix the file with its address (.hgsub) and write anything there (for example, the path on your local filesystem), but this is unscientific. Scientifically, if you use the [subpaths] section in .hgrc.
When you push changes to the main repository of the main project, the changes and the nested project are automatically pushed. It's good. My advice is to avoid the materialization of beautiful intricate drawings that draw in all the guides for “beginners” (about the possibility of pushing commits across distant land).
Flashback
I began to familiarize myself with distributed systems using the example of Git, simply because I occasionally come across references to it. I didn’t find the sane GUI-client and they all say with one voice, only Mercurial has it, and its name is TortoiseHG. In the process of casual mentioning in a conversation with a friend, it turned out that his voice was also on the side of Mercurial. And the other two, too.
Loved the landmark on antiquities. For example, I found only in minted comments that importing the repository from SVN to Mercurial does not require dancing, as described in the trillion manuals (including the combat wiki ), guides, etc. - hg convert svn ... works directly from the TortoiseHG box. And it did not happen yesterday, it works for several years.
The same landmark on antiquities and spherical horses when compared with SVN. Oh, how sad it is that the multi-week brunches without a merge with a trunking then sweep with conflicts! Oh, how sad it is that we can not commit code that does not work, because we Krivorukov developers do not do brunches! But the beautiful Mercurial / Git smogzit everything very smoothly, because la la la la and brunches are obtained automatically with cloning. First, all comparisons are made for some reason with the version of Subversion somewhere 1.2-1.4, before major changes in 1.5 and with 1.7 on the nose. Secondly, if a few weeks do not merge with the dev branch, then you will miss the changes that are not related to the merge - the signatures of the methods will change, the interfaces and so on, everything will be fine, but it will not work.
In the opposite direction are the same horses, only the version of Mercurial is taken 0.9. You can't, you see, create nested repositories. The Russian translation still says that Mercurial was not created for this. In the English version, there are already links to Subrepository , but only a few years have passed, in March 2010, even support for the embedded Subversion appeared.
Source: https://habr.com/ru/post/112968/
All Articles