5 ms·

I have been wondering whether to go back to Subversion myself. The distributed option really doesn't apply to me, my minimal branching needs are met by Subversi

by chaz72 12y ago

I have been wondering whether to go back to Subversion myself. The distributed option really doesn't apply to me, my minimal branching needs are met by Subversion, and oh my god, git's submodules get confusing.

gecko 12y ago
(Author here) To be clear, in real life, I do not actually like Subversion. I use Mercurial pretty exclusively for my own stuff, and would indeed use some of the centralized Mercurial extensions I linked in the article (e.g., remotefilelog, narrowhg, etc.) to scale upward if I had really big stuff flying around. The article is more about pointing out that going to a DVCS involves trade-offs, acknowledging that we have a lot of tooling designed to fake out those trade-offs, and discourage thinking of DVCS as a strict upgrade rather than an engineering decision with implications and costs and benefits.
- chaz72 12y ago
  Oh, no doubt Subversion has its downsides and Mercurial is really good at what it does. I was just musing through my own tradeoffs. It is a very narrow point but one that I hope is in the spirit of the article. Partial repo checkouts, SVN externals are the two areas where I feel I lost something when "upgrading" to Git. So yes, I quite agree, there are definitely tradeoffs.
liveoneggs 12y ago
why are you using submodules if your needs are simple?
- chaz72 12y ago
  Dependencies from other repos. Is there a better way that's the equivalent of a Subversion external?
  - liveoneggs 12y ago
    I would just import them directly like a vendor branch. http://marc.info/?l=git&m=119495815518898&w=2 http://marc.info/?l=git&m=119495815518898&w=2 It works like this: (I just did this test) #inside of your repo git remote add vendor $vendor.git git fetch vendor #grab their code git merge vendor/master #imports their code into your repo git mv vendorlib lib #move it where you want git fetch vendor #grab the next version git merge vendor/master #git remembers your mv from before *update of course since this is git there is yet-another-command called git read-tree to do a lot of this. It's all described here: http://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging http://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
  - Mathiasdm 12y ago
    One alternative to consider is Mercurial (which command-line wise is more similar to Subversion) with subrepos (which have better usability): http://www.selenic.com/hg/help/subrepos http://www.selenic.com/hg/help/subrepos
    - chaz72 12y ago
      Thanks, I will look into this.

by chaz72 12y ago

gecko 12y ago

(Author here) To be clear, in real life, I do not actually like Subversion. I use Mercurial pretty exclusively for my own stuff, and would indeed use some of the centralized Mercurial extensions I linked in the article (e.g., remotefilelog, narrowhg, etc.) to scale upward if I had really big stuff flying around. The article is more about pointing out that going to a DVCS involves trade-offs, acknowledging that we have a lot of tooling designed to fake out those trade-offs, and discourage thinking of DVCS as a strict upgrade rather than an engineering decision with implications and costs and benefits.

chaz72 12y ago
Oh, no doubt Subversion has its downsides and Mercurial is really good at what it does. I was just musing through my own tradeoffs. It is a very narrow point but one that I hope is in the spirit of the article. Partial repo checkouts, SVN externals are the two areas where I feel I lost something when "upgrading" to Git. So yes, I quite agree, there are definitely tradeoffs.

liveoneggs 12y ago

why are you using submodules if your needs are simple?

chaz72 12y ago
Dependencies from other repos. Is there a better way that's the equivalent of a Subversion external?
- liveoneggs 12y ago
  I would just import them directly like a vendor branch. http://marc.info/?l=git&m=119495815518898&w=2 http://marc.info/?l=git&m=119495815518898&w=2 It works like this: (I just did this test) #inside of your repo git remote add vendor $vendor.git git fetch vendor #grab their code git merge vendor/master #imports their code into your repo git mv vendorlib lib #move it where you want git fetch vendor #grab the next version git merge vendor/master #git remembers your mv from before *update of course since this is git there is yet-another-command called git read-tree to do a lot of this. It's all described here: http://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging http://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
- Mathiasdm 12y ago
  One alternative to consider is Mercurial (which command-line wise is more similar to Subversion) with subrepos (which have better usability): http://www.selenic.com/hg/help/subrepos http://www.selenic.com/hg/help/subrepos
  - chaz72 12y ago
    Thanks, I will look into this.