Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Programming IT Technology

SVN's svn:externals To GIT's Submodule 40

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."
This discussion has been archived. No new comments can be posted.

SVN's svn:externals To GIT's Submodule

Comments Filter:
  • by 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?
    • by Atti K. ( 1169503 ) on Friday February 01, 2008 @09:47AM (#22260762)
      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: (Score:3, Informative)

        by Entrope ( 68843 )
        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: (Score:3, Interesting)

      by MartinG ( 52587 )
      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.
    • by toad3k ( 882007 )
      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
      • by flink ( 18449 )
        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 [bestpractical.com].
      • 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).
        • by toad3k ( 882007 )
          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
    • 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
      • Use svnmerge[.py] - it's still almost slower than the pitch drop experiment, but it does do the job.
        • 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 (Score:5, Interesting)

    by Mr2cents ( 323101 ) on Friday February 01, 2008 @09:38AM (#22260622)
    There's an interesting talk about git on youtube [youtube.com], if you want an introduction to the program.

    And don't believe Linus when he says he's not a good speaker.
    • Re: (Score:3, Informative)

      by mcnazar ( 1231382 )
      Its a very informative and quite funny talk actually. Google Video host another GIT video here [google.co.uk].
    • Re: (Score:3, Interesting)

      by XaXXon ( 202882 )
      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
      • by jhol13 ( 1087781 )
        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.
  • 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) [google.com]

    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.
    • by Aladrin ( 926209 )
      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.
  • by Dionysus ( 12737 ) on Friday February 01, 2008 @10:11AM (#22261138) Homepage
    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: (Score:2, Informative)

      by mcnazar ( 1231382 )
      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.
      • by Dionysus ( 12737 )
        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.
  • 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?
    • >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...
    • > 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 [rubyforge.org], monotone [rubyforge.org], darcs, etc. There's a request in for git [rubyforge.org], too. Just need to take some time and set that stuff up and see which ones folks start using, I guess.
    • 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
      • 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 does

      • 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 some
        • by Mr2001 ( 90979 )

          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.
          • 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.
    • 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
  • 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 [evil.che.lu]

    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 [peepcode.com]

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Working...