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 mailing list
[email protected]
http://mailman.metalforge.org/mailman/listinfo/crossfire
