Re: [crossfire] Crossfire should use Git
On 06/14/14 11:30 AM, Kevin Zheng wrote: snip I believe the most compelling reason to use a DVCS is that it makes contributions easier. About a year ago a common complaint about my patches were that too many changes were lumped together in one patch, making it hard to review. While I could have used Git or Hg to make a local repository, I did not think that was worth the trouble. True - a DVCS certainly makes it easier to have/make multiple unrelated changes and make them available as individual patches (presuming good practices were followed and the developer remembers to check them in their local repo separately). I also think DVCS is also better if one is making really big changes that will take a while to do, because of the better branching, local commits, and merging - for something like SVN, you would pretty much need to make your own branch, which then also shows up in the main repo. Next, an adventure: I've taken the liberty to install and attempt to learn Mercurial. Since I am brainwashed by the Git world, please correct me if I'm wrong. My current workflow involves putting all non-trivial or multi-commit projects in a separate branch. Then I dangerously reorder, squash, and otherwise mutilate my local branch until it can be laid on top of the SVN trunk, where I dump back the linear history. If I used Hg, this would likely involve making many copies of the repository (since each branch is an entire checkout) for minor changes. Since I make extensive use of the Git staging area, I would wind up using `hg record` (an extension) very often. I would also end up maintaining patch sets using message queues (another extension), in order to clean up my changes before committing. In addition, it would be impossible for me to rebase my commits, which means that every branch would require its own merge. If you take a look at my commits, most have been squashed versions of local branch work. I'm not at all familiar with git, so I'm 100% how to compare the 2. I'm not 1005 sure why you would need many copies of the repository - there is nothing that prevents making a clone, making one set of changes, doing a local commit, making another set of changes, doing a local commit, and repeat as necessary. The only reason you would need many copies of the repository is if you were making different changes to each one - you could still do that with hg, but that seems like a somewhat odd way to develop code. Note you can reparent with mercurial quite easily - presuming there is a common parent, it is just a matter of doing 'hg pull newparent'. You can likewise do the same with the push, but you need to be up to date relative to the parent (mercurial will make sure this is the case). All that said, at work, we use the cadmium extensions which provide some nice features like 'recommit', which collapses all the commits in the branch into a single delta which can be pushed later. I'm not sure how available the cadmium tools are. But whether people use extensions or not for mercurial doesn't matter much - those extensions are local to them, and the main repo doesn't really care. So people can use whatever extensions work best for them. I advocated Git because we should use the VCS that I'm most familiar with. It works with the workflow that I'm most comfortable with. I welcome anyone familiar with Hg to reeducate my current workflow. If I am the only developer that makes use of such a workflow, then I apologize for being selfish and greedy. The problem is that if I took that attitude several years ago, we probably we be on mercurial. Crossfire is a community project, so has to meet the needs of many developers. While SVN is pretty limiting, one thing it has going for it is that it is quite simple to use - non hardcore developers can understand and use git without much problem - from many of the other posts I've seen, that is not true with git (and mercurial for that matter). So having something simple and easy to use has lots of advantages, with limited disadvantages (main one being that SVN is not a DVCS) Git has a good SVN bridge. Hg has a good Git bridge. Git does NOT have a good Hg bridge (Git's fault). If I keep my current workflow, then I'd much rather stick with SVN and play with local Git branches. IMO, that may just be the simplest way to go - I understand it is more pain for you, but there is a fair amount of pain to switch what VCS crossfire uses (I did this one before) - aside from the different commands people need to know, everyone also has to point to the new repo, you have to make sure there are not any outstanding commits, etc. Plus, from the other people that replied, there clearly was not an unanimous chorus of everyone agreeing to a move to git - granted the number of replies was limited, but if anything, seemed to be more opposition to it than those in favor. ___ crossfire
Re: [crossfire] Crossfire should use Git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, First, a few responses: Many of the reasons I mentioned do extend to most DVCSs, and this is the fault of my own (thinking that Git == DVCS). I'll concede that Git has a fairly steep learning curve, although I'll assert that it is harder to use a pneumatic drill than a hammer. I learned Git after SVN and it was not a big problem for me. I believe the most compelling reason to use a DVCS is that it makes contributions easier. About a year ago a common complaint about my patches were that too many changes were lumped together in one patch, making it hard to review. While I could have used Git or Hg to make a local repository, I did not think that was worth the trouble. Next, an adventure: I've taken the liberty to install and attempt to learn Mercurial. Since I am brainwashed by the Git world, please correct me if I'm wrong. My current workflow involves putting all non-trivial or multi-commit projects in a separate branch. Then I dangerously reorder, squash, and otherwise mutilate my local branch until it can be laid on top of the SVN trunk, where I dump back the linear history. If I used Hg, this would likely involve making many copies of the repository (since each branch is an entire checkout) for minor changes. Since I make extensive use of the Git staging area, I would wind up using `hg record` (an extension) very often. I would also end up maintaining patch sets using message queues (another extension), in order to clean up my changes before committing. In addition, it would be impossible for me to rebase my commits, which means that every branch would require its own merge. If you take a look at my commits, most have been squashed versions of local branch work. I advocated Git because we should use the VCS that I'm most familiar with. It works with the workflow that I'm most comfortable with. I welcome anyone familiar with Hg to reeducate my current workflow. If I am the only developer that makes use of such a workflow, then I apologize for being selfish and greedy. Git has a good SVN bridge. Hg has a good Git bridge. Git does NOT have a good Hg bridge (Git's fault). If I keep my current workflow, then I'd much rather stick with SVN and play with local Git branches. Thanks, Kevin Zheng -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTnJS1AAoJEOrPD3bCLhCQvq8H/RvwMBwd3N1F13IXM6URjAiE TVMQ/eFf3XjKq9048NOd64YTCsCRyBKZt7PUOVlaUnaIRAcblwMyGLWuvwIlQOwZ CImrQi+66YkeKoFB5GEH9bCLDhHzDNQu2GsZVNTnTF/AUeYpJdiwiOlaJMqpVKyh lhdzCNJNR2GAe/aT7HdDnlq/Z/CIvngpWQqc++WaLQLmoYvw0gqWWM5yGxiAzo+l +vR24q0LxSTvtAc1E8mLX15eQx3Z+8Q0/Dbdd0TT78AX1DDMH2teAkumWcuRGDot IMM6c9DofKvEL2B0I2Y15tH6RFYhzpcexKssP8h5zFAuFMBMbcY2QszvHy63jbY= =rfsf -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire should use Git
/me throws some plain non blessed water to squash the religious war Nicolas Le vendredi 13 juin 2014 15:13:22, Kevin Zheng a écrit : Hi all, Crossfire originally lived in the world of CVS, until a handful of brave knights ventured to move it to SVN. Today I believe it is time to move again, and this time to Git. Git is a distributed version control system, which means that checking out an old revision or reading the commit log does not require accessing the sometimes painfully slow servers on the Internet. Each 'clone' of the repository is a fully-functioning repository on its own. This means that developers, even those who do not have commit access, can work on projects at their own pace and submit them with tools such as `git format-patch` and others. Git makes branching easy. It makes maintaining them manageable. As an example, several important fixes were made in 'trunk', which have yet to be backported to 1.12.0. In addition, there are no release engineering branches, which means that each release is simply cut from the next 'trunk' state in line. Even trivial fixes could benefit from topic branches, but SVN does not make this easy, convenient, or fun. Using Git branches would help create a more stable codebase by improving release engineering and adopting intermediate stable branches that servers can track. A recent autotools bug that wiped server configuration files, for example, could have been prevented if changes on the bleeding edge were evaluated by test servers first. Git is not terribly difficult to use. Right now I access the SVN repository through a local Git clone, but this is inadequate because I cannot publish my topic branches (without considerably difficulty). A migration that preserves tags, branches, and full revision history can be made as fast as the revisions are pulled from SVN. In summary, a few important benefits of using Git: - Contributors can work on the code easier, with revision control. - Distributed, so works without (slow) Internet access. - Encourages branching - more stable codebase. - Easy to use and migrate to. - Full (all revision history) repository size: 21.7 MiB (server), 13.9 MiB (client), 106.1 MiB (maps) However, there are a few immediate problems: Most projects using SVN make extensive use of the revision number identifiers. Crossfire is no different. Git has revision (commit) identifiers, but they are meaningless without the repository, whereas SVN increments the number for each commit. I do not believe this is an issue, because client compatibility is not determined by this specifier, plugin versions are only checked to match, and other uses of the identifier can be removed. Of course, comments, questions, and hate mail are always welcome. Thanks, Kevin Zheng ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire should use Git
I'm not a regular contributor either but I believe mercurial (hg) is the better choice as well. Plus the site Bloody Shade mentioned http://hginit.com/ easily explains the transition from svn to hg. On Jun 13, 2014 9:29 AM, Bloody Shade bloodysh...@gmail.com wrote: I'm not sure I can agree with a move to Git, personally. There's plenty of drawbacks that also come with git (not that other version controls don't). I personally use mercurial (hg) for my projects and you can find more info on it and see if you like it at: http://hginit.com/ I found this article with some things I also don't like about git, in case anybody else is wondering (although I'm sure there's more): http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ Then again, I'm not a regular contributor, so feel free to ignore this, but I thought it would be worth throwing my 2 cents. On 6/13/2014 10:13 AM, Kevin Zheng wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Crossfire originally lived in the world of CVS, until a handful of brave knights ventured to move it to SVN. Today I believe it is time to move again, and this time to Git. Git is a distributed version control system, which means that checking out an old revision or reading the commit log does not require accessing the sometimes painfully slow servers on the Internet. Each 'clone' of the repository is a fully-functioning repository on its own. This means that developers, even those who do not have commit access, can work on projects at their own pace and submit them with tools such as `git format-patch` and others. Git makes branching easy. It makes maintaining them manageable. As an example, several important fixes were made in 'trunk', which have yet to be backported to 1.12.0. In addition, there are no release engineering branches, which means that each release is simply cut from the next 'trunk' state in line. Even trivial fixes could benefit from topic branches, but SVN does not make this easy, convenient, or fun. Using Git branches would help create a more stable codebase by improving release engineering and adopting intermediate stable branches that servers can track. A recent autotools bug that wiped server configuration files, for example, could have been prevented if changes on the bleeding edge were evaluated by test servers first. Git is not terribly difficult to use. Right now I access the SVN repository through a local Git clone, but this is inadequate because I cannot publish my topic branches (without considerably difficulty). A migration that preserves tags, branches, and full revision history can be made as fast as the revisions are pulled from SVN. In summary, a few important benefits of using Git: - - Contributors can work on the code easier, with revision control. - - Distributed, so works without (slow) Internet access. - - Encourages branching - more stable codebase. - - Easy to use and migrate to. - - Full (all revision history) repository size: 21.7 MiB (server), 13.9 MiB (client), 106.1 MiB (maps) However, there are a few immediate problems: Most projects using SVN make extensive use of the revision number identifiers. Crossfire is no different. Git has revision (commit) identifiers, but they are meaningless without the repository, whereas SVN increments the number for each commit. I do not believe this is an issue, because client compatibility is not determined by this specifier, plugin versions are only checked to match, and other uses of the identifier can be removed. Of course, comments, questions, and hate mail are always welcome. Thanks, Kevin Zheng -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTmvjyAAoJEOrPD3bCLhCQsEIH/2CnCPs/FmKlGmgkMw98zo/b vIFMiFiMZsuEteKUajXZb3+OfabyvCTBJZc3nVOlVwxt6xT+9NcspmdPYIofqt2M 24fhSY7LqSF5Odc/afQX6JrA21fgF/ryU6jc1Iri2+13Wk6TDEhQqZ/ASdSmaaZm IXd9iPb8D7EbSmp0pqvAGKriExVZDSIuukXmOQzbjG8mqFgczBnNdxP62bPh2H03 NyMbd+nCFfaaXAca/5wGZgrqmx0OU8DiRx9FTKzwp1/Ku3t09PT9aUbuOY6qUKAU kdOQfdp8naAxCbf38B/9k+IU5lk+JFcbs576X3lreU0xyr1byZyparkfNOLk3XE= =lsHS -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire should use Git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My questions on going with a distributed revision control has to do with how does all these changes in a branch make it back to the main code base? This is not a question in regards to command syntax and code merging practices. It's more on a administrative or QA level. Perhaps I'm asking who brings in all the changes from the branches to the main code base? Thank you, Rick Tanner -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iD8DBQFTm4NQhHyvgBp+vH4RAvepAKCmTqzcsL28o6Q96Xm2CbxgNr1/QQCfUzY1 BjzHRN1yAdfmRHPBkU7OtmU= =KBE3 -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire should use Git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/13/2014 18:03, Rick Tanner wrote: My questions on going with a distributed revision control has to do with how does all these changes in a branch make it back to the main code base? Perhaps I'm asking who brings in all the changes from the branches to the main code base? I expect that branch maintenance and integration will remain pretty much the same. Developers who choose to publish topic branches should ultimately merge in changes when the code is ready. Contributors who wish to make changes should make local commits and generate patch sets. Contributors wishing to make extensive changes can seek the help of a developer with commit access. Keep in mind that it is not necessary to work in topic branches; the current workflow can stay the same. I expect that more people will use and publish branches, though. Thanks, Kevin Zheng -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTm4n8AAoJEOrPD3bCLhCQB9YIAL740CWrMriZ2Vi3JokSESxa CG7qAecR2ELrD61FpDiLY04g2fAZdAMDoxPzeRX4i3mY+uwaWrzdie74/J8ufqB5 6aFyB0YEXHXr07CFFyRJWa09FXuPXgVZxzYU4vFLCkUspBujVdGmUbrsZdLHFxvR qAxGSNhFVQyKUQvfJBrbu+mitJK2x2b15sigZOticKHfnkEQNCE3UKjBFM314QgQ ps++0nusn1nQX9MrP5tl/gJV3ScfRZW81Eh6GkAcZPANlsajK4Hlrw88S3t/6l24 Q5oDEJE19XdrCkzwNLPpQhlQ9lvfTi/0/xGB9+jmWAZ9K3kx0UIcxZu3guAPT1A= =6Axm -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire should use Git
Whenever these discussions come up (this is probably the 3rd or 4th iteration), the general response is 'we should use the VCS that I'm most familiar with' So on that basis, I'd vote for mercurial (use it at work) or SVN (crossfire already uses it) All that being said, for the amount of commits crossfire gets, I'm really not convinced a distributed VCS is worth the effort. It is certainly useful for really big projects, or if making lots of changes such that you want to be able to do intermediate commits. To me, the only really compelling reason for a DVCS is that all the data is local, so you can do things like diff, history, etc, and still get data even if the master gate is down. I don't think it will make much difference in terms of maintaining branches - all systems I've seen have problems once branches drift apart - at some level, manual merging is possible. Its been a while, but I seem to remember that even for SVN, there was a pretty simple way to do that. The main problem (in general) with branches is people just generally don't want to do the extra steps to backport, even if the steps were pretty trivial. I'm really not convinced that a bunch of branches are desirable thing - whenever extra branches have shown up in SVN, they basically just languished, and I don't think it was because of the VCS, but rather there are not so many developers that your going to have 10 people working on the trunk and 8 playing on a branch - rather, everyone just works on trunk. Conceivably, this can be useful if working on a private branch, but a DVCS really doesn't help prevent merge hell if the branches drift too far apart (conflicts still need to be resolved by hand), though I suppose with a DVCS, they would need to be resolved less often vs trying to use SVN. mercurial at least can pull from a SVN repo, as it sounds like GIT can, but the issue is the push. I have no idea if git and mercurial can play well together (if the repo was mercurial, can git do most things it needs to do or vice versa). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
