SVN's svn:externals To GIT's Submodule

mcnazar writes "Do you manage your Rails Plugins via svn:externals? Thinking of switching to Git but are concerned that Git lacks a direct equivalent of svn:externals? In this article I present a work-around or even IMHO a better solution than SVN's svn:externals."

Comments

SVN branching a daunting task?

[Anonymous Coward]

FTFA:

[Git] encourages more experimentation in your code by making branch a trivial as opposed to a daunting task. Because svn cp $REPO/trunk $REPO/branches/my_new_branch is too scary?

Re:SVN branching a daunting task?

[Atti K.]

Branching is easy. Merging them together again... well... What SVN lacks is merge tracking (a la ClearCase, for example - which is otherwise a horrible product, but that's not the point here). They plan to introduce it in 1.5, though.

Re:SVN branching a daunting task?

[Anonymous Coward]

Merging such branches is trivial, if you follow this rule:

1. you can merge from trunk several times (add the rev into commit message)
2. once you merge to trunk, delete the branch and open a new one for new stuff.

Re:SVN branching a daunting task?

[MartinG]

When you have large numbers of developers all creating their own experimental branches, the repo becomes a mess. Of course all the distributed tools fix this by design.

Personally, when I have to interact with a project that uses svn (as I do daily in my job) I use bzr with its svn integration.

Re:SVN branching a daunting task?

[Entrope]

Proper merge tracking has been on the "we plan to introduce it" list for Subversion since well before 1.0, along with a few other things that most strongly-formal customers expect from version control systems (like useful history tracking/recovery in the face of file renames; issue #928). At least they claim merge tracking is actually on trunk now (issue #820) -- I'll believe it works decently when I see it.

Re:SVN branching a daunting task?

[lagfest]

Merge tracking is the main feature of 1.5, which, according to this guy, is in beta right now. He does a demo of it too.

Re:SVN branching a daunting task?

[Anonymous Coward]

svnmerge.py isn't exactly daunting either.

Re:SVN branching a daunting task?

[toad3k]

The problem isn't that making a branch is hard. It isn't hard. The problem is that when you make a branch, everyone else in the repository sees it listed. You end up with 100 branches in the project with random names like daves_branch1, and dev2, and test12. Which ones are even seeing active development? Which branches are important department wide branches and which ones are personal developer branches? Do we have to make special naming rules and threaten people to bring order to it? If you have to implement rules to clean up this mess, does it prevent people from branching in the first place?

Well I'd say it does. I've actually never seen a single company use subversion branching the way it was intended. I've seen people jump through hoops to avoid creating a new branch. People write code and don't commit it until it is finished because branching has all sorts of rules attached to it. And so what happens when half a dozen people wait two weeks in between commits? Well exactly what you'd expect to happen. Coordination suffers.

The only way I've found to explain it is that you'll never realize how bad cvs/subversion is until you've used something better.

Re:SVN branching a daunting task?

[SanityInAnarchy]

No, more like:

svn merge $REPO/trunk . -r...^C
svn log ... ...
#shit, this is taking too long
^C
svn log --limit 10 | less
svn merge $REPO/trunk . -r123:HEAD
# Now go resolve some conflicts

This is less painful if you do it often, because there will be fewer conflicts and surprises. But doing it often is, itself, painful, because of how needlessly complex that process is. And then when it's time to merge back to trunk, well, first you do the above, then you do this:

cd ../trunk
svn update -r...^C
cd ../mybranch
svn log --limit=1
cd ../trunk
svn update -r456
svn merge $REPO/branches/mybranch . -r...^C
cd ../mybranch
svn log --limit=10 | less
# Oh right, I do need everything this time
svn log | less ...
# Alright, coffee time ...
# Let's see what's on YouTube ...
# Finally!
cd ../trunk
svn merge $REPO/branches/mybranch . -r123:HEAD
svn update
# Grr, more conflicts
svn commit

So that was a bit exaggerated, and it's actually tolerable for what people use branches for in Subversion. But having branching/merging actually be easy opens up a few possibilities -- like being able to "commit" a change to your branch almost every time you save, and not having to worry about it being "done" for you to get the benefits of version control. And then, when you want everyone else to see your changes, bundle them all up in one neat patch (or changeset) and send them in. You certainly wouldn't commit as often to a central repository -- who wants the CI system spamming you (and everyone else) for every typo?

That's how I understand it, anyway. I do use svn at work, but I've been considering using something like bzr to maintain all my local checkouts.

And yes, you could do something like this with svn, but making it easy is a Good Thing.

Re:SVN branching a daunting task?

[flink]

What I've done in our repository is create a /users tree. Every person with commit access gets a directory here if they want one. People have free reign to do whatever they want within their user area. They can create as many private branches as they need without fear of fouling up the /branches tree.

Alternatively you can use svk.

Re:SVN branching a daunting task?

[Breakfast Pants]

Huh? Branches are versioned in subversion just like everything else; you can simply svn delete the branch directory (and unlike the git solution--keep your branches to yourself and rebase them out when you commit--you can subversion branches back).

Re:SVN branching a daunting task?

[Bitsy Boffin]

Use svnmerge[.py] - it's still almost slower than the pitch drop experiment, but it does do the job.

Re:SVN branching a daunting task?

[toad3k]

You can push branches if you want in git. You can have as many project branches as you like. But you aren't required to push every branch to the main repository. So you can go off on a tangent, make a small demo, show some people, share it, and if it develops into something, push it to the main repo for others to look at, but only if you want to.

As for versioning branches? Why would you? If you delete a branch, you must not need it for anything. Why archive it? If you need it, don't delete it in the first place. That's what tags are in git, they are just branches with names. When you don't need it anymore, you delete it and it is gone forever. If you merged it into something else, its changes will be preserved, otherwise its history will be removed from the repository as though it had never existed. I have never had an occasion to search for or attempt to resurrect a deleted branch before.

Re:SVN branching a daunting task?

[Breakfast Pants]

Why settle for losing any history?

Re:SVN branching a daunting task?

[SanityInAnarchy]

One more advantage: My local branch in a distributed rcs is local, as in, not affected by my Internet connection (or lack thereof).

Can svnmerge do that?

GIT lecture

[Mr2cents]

There's an interesting talk about git on youtube, if you want an introduction to the program.

And don't believe Linus when he says he's not a good speaker.

Re:GIT lecture

[mcnazar]

Its a very informative and quite funny talk actually. Google Video host another GIT video here.

Re:GIT lecture

[XaXXon]

I just watched it.. I can't believe it was 70 minutes. Other than the aggressive passive-aggressive stuff he kept doing throughout the talk, it was quite good. It got me excited enough to go try git.

Again I was impressed. It has been a while since I've tried git and I was amazed at how easy it was to do some easy stuff. I grabbed a source tarball and built it (on my mac) and it installed perfectly. Then I used it git to get the git source via http. That worked flawlessly. I went through some examples on the git site on the git code and it was all really nice. Everything made pretty good sense and just worked.

The only thing was getting the man pages installed locally.. and in that case, I logged into #git on freenode and someone immediately helped me, even though os x's tar is lacking standard functionality and the immediate command they gave me didn't work.

All I can say is WOW.

Re:GIT lecture

[jhol13]

I have no experience on GIT so I cannot say how good it is.

But I have used both SVN and Mercurial. Boy, the Mercurial has totally superior features compared to SVN. It has much better support for move and especially merge that it really makes SVN look as a childs toy in this respect.

I have not used them so much as to claim either is better overall (robustness, multiplatform support, integration other tools, etc.). But the merge on SVN really sucks.

Wha-?

[Anonymous Coward]

I didn't understand a word of the summary. I feel a right git.

Thundercats Ho!!!!!

[powerlord]

I realize this is only tangentially on-topic, but did anyone else notice that the logo for Panther Software Publishing (in the upper left corner of the page in TFA above), is a flipped and color changed version of the old Thundercats logo (here for instance)

As far as I can tell, it looks like it might be a direct steal, with a little bit of cleanup. I'm a bit surprised that any company would be using a stolen image as their logo.

Re:Thundercats Ho!!!!!

[Aladrin]

I agree, it's identical. They may not even know the logo was stolen... They may have paid someone for a logo and that someone was the thief.

I wrote an email to them to inform them, in case they didn't know.

svn:external vs git submodules

[Dionysus]

I actually find svn:external a little more flexible than git's submodules. With svn, I can create a submodule/external for a given directory (say the module has the following subdirs: src and docs, you can pull in just src), while in git you would have to pull in the whole repos (correct me if I'm wrong)

Re:svn:external vs git submodules

[mcnazar]

You are correct in that Git does not support partial checkouts. This has been the biggest hurdle in my SVN to Git transition. Yes it is a pain but the benefits I gain (disconnected development from my SVN respository whilst off the network) makes up for this.

Re:svn:external vs git submodules

[Dionysus]

I totally agree that the gains more than make up for the pains. I pretty much moved all my development over to git. I still miss that feature, though.

Silly name, great software

[00_NOP]

I switched to GIT for tracking my Linux kernel work a few months ago and once I'd gotten used to it I wondered why I'd spent all that time using CVS and then SVN (yes, I know git wasn't available before). GIT is generally being credited with the accelerating pace of Linux kernel development. As a serious question, other than the hassle of a switch, are there good reasons for sticking with CVS or SVN or is GIT now The One True Way?

Re:Silly name, great software

[mcnazar]

>are there good reasons for sticking with CVS or SVN or is GIT now The One True Way The more I work with Git standalone or as a front end to SVN the more I think is is "The One True Way". The new batch SCMs (ie Git, Hg, Darcs, Bzr...) have definitely made things more interesting. Makes you wonder why several corporate clients insist on just or still using VSS...

Re:Silly name, great software

[tcopeland]

> are there good reasons for sticking with CVS or SVN
> or is GIT now The One True Way?

Seems like the other distributed SCMs have their fans too; I've gotten requests on RubyForge for Mercurial, monotone, darcs, etc. There's a request in for git, too. Just need to take some time and set that stuff up and see which ones folks start using, I guess.

Re:Silly name, great software

[Anonymous Coward]

I use git for most of my projects, but I have a few projects where I've used svn because of its solid integration with Trac. If Trac had better git support, I'd use git everywhere.

Re:Silly name, great software

[chthon]

Do not forget bazaar...

Re:Silly name, great software

[snoyberg]

My guess is that Ruby people don't want a Python SCM solution.

Re:Silly name, great software

[psykocrime]

As a serious question, other than the hassle of a switch, are there good reasons for sticking with CVS or SVN or is GIT now The One True Way?

I'm assuming you mean in the general case and not just linux kernel development? If I misunderstood what you were asking, ignore the
rest of this reply. :-)

I don't use git, so this is pure hearsay and might be inaccurate, but the one semi-compelling argument I've heard against git is this:

IF your project is multi-platform (or, god forbid, windows only) and some subset of developers work on windows; supposedly hit was pretty
weak client support on win32. Linus obviously (and for good reason) doesn't give a rat-fuck about making git work on win32, so there is
just (last I heard) an unofficial win32 client for git.

Take that for what it's worth...

Re:Silly name, great software

[Anonymous Coward]

My guess is that Ruby people don't want a Python SCM solution.

Nope, if they didn't they wouldn't want Mercurial either. Besides, it's mostly the Python fundies who are zealous about such things.

Re:Silly name, great software

[Anonymous Coward]

>doesn't give a rat-fuck about making git work on win32 Thankfully this is open-source software which many people can, and do, contribute to. Last I heard the MSYS port of Git is coming along nicely. I would be concerned if say this was a closed source app, which nobody wanted or gave a rats ass about... ie Vista.

But is it the correct hammer?

[Gazzonyx]

I work alone on projects (I'm a software development student), I rarely have full blown branches or full blown versions (I use a major.minor.fix notation where odd minors are unstable, but I don't have a roadmap as to what version number has which features). While I use git somewhat (read: with a man page on term. 2) when reading kernel code or for kernel hacking, I'd never use it for my school or work projects; I use svn for them, and not even with all its features (barely any tagging, branching, merging). Basically, I just want a place to commit my code that integrates in to whatever IDE I may be using at that time, as I work with 5 or 6 languages at any given time. It needs to backup easily, and stay out of my way otherwise. Diff output is icing on the cake. If I take a wrong turn somewhere, I can revert to a previous commit or apply a diff against one commit from another, and I have annotations for each commit so that when I go back a few months later and ask, "what in the world was I doing this for?", I can just read the commit annotations.

Git, while cool, provides me nothing in the way of features I need at the cost of a somewhat steep learning curve. It's just not the tool for my current job. I need a light duty hammer that fits my tool belt. Git is the belt fed, compressed air, master carpenters nail gun; it's really, really cool, but is entirely overkill for my needs and does not fit my tool belt at all. Furthermore, it comes with a heavy manual that I'd better read if I'd like to keep all my fingers!

To summarize, every tool has a problem it's supposed to solve, otherwise it has no reason to be invented, if a given tool is not fixing my problem, then it does me no good.

Re:But is it the correct hammer?

[Chandon Seldon]

Git is the belt fed, compressed air, master carpenters nail gun; it's really, really cool, but is entirely overkill for my needs and does not fit my tool belt at all. Furthermore, it comes with a heavy manual that I'd better read if I'd like to keep all my fingers!

I don't know about that. I've been using git on my latest single-developer project just as a way to keep a log of changes and roll back stupid mistakes - basically the same stuff you're using SVN for.

Git has one huge advantage over SVN - it doesn't need an external repository to commit to because every checkout is also a complete repository. This does mean that "committing" and "creating an off-machine backup" are different operations. Also, the "IDE" I use is vim in a terminal window, so integration isn't an issue at all.

In conclusion, you're right - Git is a different tool from SVN, but you seem to have overrated how different and imagined a massive complexity difference that isn't there.

Giston for managing SVN externals from Git

[muchawi]

I use Giston for linking to SVN repositories from Git. It works like the piston counterpart for Subversion and allows me to update the local copy when I choose to.

http://evil.che.lu/2008/1/18/ann-giston-0-2-0

SHAMELESS SELF PROMOTION

I produced an hour-long screencast tutorial on Git that has helped many people. Technically edited by Junio C. Hamano, available in Quicktime or Ogg Theora:

http://peepcode.com/products/git

Not Git, but

[SanityInAnarchy]

Most of these are going to have pretty much exactly the same syntax as svn, which is pretty much exactly the same syntax as cvs, at least for simple things.

Of course, you want IDE integration, so your mileage may vary quite a bit. I would suggest that most of the learning curve is the same as the commandline svn tool, though, and you do want to know that, in case you need it. I used Tortoise for quite awhile, when I was on Windows, but every now and then, I'd have to grab the commandline svn client for something stupid, like being able to rename multiple files on the local machine and have it show up as one commit (the next one, to be precise).

Also, because of the ease of setup, I find myself using something like bzr much more often for one-man projects, realizing that if someone else has to jump in at some point, it's as simple as emailing changesets. (Think of a changeset as a set of patches which can be merged as a chunk of revision history.) And knowing the commandline tools means I'm not tethered to any given IDE or editor.

Re:Not Git, but

[Mr2001]

I used Tortoise for quite awhile, when I was on Windows, but every now and then, I'd have to grab the commandline svn client for something stupid, like being able to rename multiple files on the local machine and have it show up as one commit (the next one, to be precise). Can't you do that with Tortoise? Just use the context menu to rename them in your working copy, then commit once you've renamed all of them.

Re:Not Git, but

[SanityInAnarchy]

Been awhile, but I'm not sure you can rename them to a different directory in your checkout, only to a different name within the same directory.

Not worth booting Windows just to make sure I'm right, though.