Clone from GitHub in Delphi IDE

There are a lot of interesting Delphi projects showing up on GitHub. GitHub offers a convenient Download ZIP function, not to mention a very easy to use Windows Desktop Client that has full support for managing local repositories, syncing them to GitHub and accessing GitHub projects via Cloning in Desktop.

Sometimes it is nice to just open the project in your IDE of choice directly from GitHub. Turns out this is just as easy as 1-2-3. Right above the Clone in Desktop and Download ZIP buttons there is a checkout URL with support for Subversion. Simple click Subversion, then click copy URL and your can then open the GitHub project directly from the Delphi or RAD Studio IDE.

github-subversion

This maintains the revision history locally so you can browse it from the history tab, but it doesn’t appear to allow checking changes back in.

You probably want to update the SVN client RAD Studio uses. This is easy enough too. Just download and install the Colab SVN 32-bit Windows client (don’t get 64-bit or Edge) and install it normally. Then edit your Registry and browse to “HKEY_CURRENT_USER\Software\Embarcadero\BDS\14.0\Subversion” and add a string value named SvnDllDir. This value of SvnDllDir should be the path to your SVN client install. Something like “C:\Program Files (x86)\Subversion Client” (without the quotes).

If you don’t like the fact the Colab Subversion site requires a login, there are other sources for download the Subversion command-line client. Just be sure you get the 32-bit version since the IDE is 32-bit. You may have luck with with the command-line tools that come with TortoiseSVN, or I’ve tested it with the Command-line client from Assembla and found it worked fine.

This entry was posted in Tools. Bookmark the permalink.

15 Responses to Clone from GitHub in Delphi IDE

  1. A. Bouchez says:

    The github for windows tool is just an inefficient and heavy bloatware. Tortoise git or even the ui shipped with msgit is much better.

  2. Robert Love says:

    The SVN option does not get SubModules, so if the project uses SubModules (JCL, JVCL) then this option will fail to get all the files.

  3. But… using like svn you lost all the git advantages. What sense have this? Why just don’t add a git client to delphi?

  4. Jerry says:

    Is Embarcadero still delivering a 5 year outdated version of svn and hiding it away in a cramped space of the ide? Its a joke, just use svn, git or hg outside the ide without the clumbsy interface.

  5. The Github for WIndows app is useless but Souce Tree i find is brilliant, fast, no bloatware , feature rich and free

    http://www.sourcetreeapp.com/

  6. @germanpablogentile: Using git you lost all the SVN advantages. What’s the sense in it? 😉

    Git was invented for Linux kernel development, and that’s the kind of project it excels at: massive scale, highly-distributed, heavily forked. I see it about the same way I see NoSQL databases: if you’re building something enormous (like Google, Amazon or Facebook, on the database side, or a full-fledged operating system on the VCS side) then it’s something you need enough to make it worth all the extra headaches and overhead, but you’re probably not, are you? So don’t bother.

    For example:

    In SVN, checking out a sub-folder containing only part of the project is trivial. In DVCS systems, it’s not supported. At all.

    In SVN, blames are highly intuitive. Each line gets a revision number next to it, and you can easily tell, for example, that code marked “57” was added after code marked “48”. In a DVCS system, there are no such thing as authoritative revision serial numbers, because there’s theoretically no authoritative central repository. (Even though in practice there almost certainly is one, unless you’re running an enormous project.) So working out chronology becomes far more complicated.

    In SVN, retrieving updates from the central server (that, again, almost certainly does exist no matter what kind of VCS you’re using) is a simple, one-step process, and posting updates to the central server is only slightly more complicated because you have to select the files to send first. In a DVCS system these two operations–the two most fundamental, most commonly used operations in the entire concept of version control!–are both highly involved processes:

    Retrieving updates requires that you pull data from the central server to your local repository. Then you tell it to resync your working copy from your local repository. Then the client notices that you have uncommitted changes in your working copy (because, be honest, you always do,) and steps in and requires you to do something about that whether or not there is any potential whatsoever for a merge conflict before you can proceed. 3 steps, or possibly more depending on how you deal with the third step.

    Posting updates requires that you select all the files you want to send, then commit them to your local repository, and then send them (or send a pull request, which is even slower and more tedious) to the central server. 2 steps.

    In conclusion, when you make the most common operations far more complicated in order to optimize for edge cases, you end up with a really horrible product in the general case that’s only really useful for edge cases.

  7. @masonwheller i suggest you trying git in a day work. How biased can be programmers on this day? 😛

    And BTW, svn is old, is time for Delphi to have a decent client for GIT, the most used in the world 8not only for kernel developers or google…)

  8. Joseph says:

    @Mason You’re comparing an actual product against “DVCS” as if all DVCS systems were identical.

    >In conclusion, when you make the most common operations far more
    >complicated

    Branching/forking and merging are very common operations and they’re both much easier with a modern DVCS than with Subversion. Even a man you quote often, Joel Spolsky, wrote a popular guide to Mercurial and prefaces it with an introduction regarding how he came to realize that DVCS was superior:

    http://hginit.com/00.html

    The problem with conventional VCS is that you’re afraid to commit unpolished or untested code that could mess everyone up. Either you commit and make everyone else unhappy, or you choose not to commit until everything is finished and perfect. Of course, this defeats the entire purpose of a VCS! With DVCS you can commit every little change to your own personal repository and then merge “upstream” when everything is done. You avoid both unpleasant alternatives.

    >In SVN, checking out a sub-folder containing only part of the project is trivial. In
    >DVCS systems, it’s not supported. At all.

    This has nothing to do with the architecture of a DVCS so you can’t generalize. But why would you want to check out “part of a project” unless your project is dumping lots of projects into subprojects hanging off a main directory? If checking out a branch is trivial, why do you need to check out a file?

    As Spolsky put it, “Subversion is basically revision control for files, but in Mercurial, revision control always applies to an entire directory—including all subdirectories.
    … in Subversion, if you go into a subdirectory and commit your changes, it only commits changes in that subdirectory and all directories below it, which potentially means you’ve forgotten to check something in that lives in some other subdirectory which also changed. Whereas, in Mercurial, all commands always apply to the entire tree.
    …This is not a big deal, but if you’re used to having one big gigantic repository
    for the whole company, where some people only check out and work on subdirectories that they care about, this isn’t a very good way to work with Mercurial—you’re better off having lots of smaller repositories for each project.”

    >So working out chronology becomes far more complicated.

    I don’t follow this at all. It’s always clear who checked in what.

    >In SVN, retrieving updates from the central server… is a simple, one-step >process, and posting updates to the central server is only slightly more
    >complicated because you have to select the files to send first.

    In reality it’s far more complicated because you have giant merges thanks to not checking in code until its completed. A DVCS has lots of little changesets to work with that make it much easier to merge code.

    > In a DVCS system these two operations–the two most fundamental, most
    >commonly used operations in the entire concept of version control!–are both
    >highly involved processes

    I don’t know what DVCS you’re thinking of. In Mercurial, it’s “hg commit” and “hg push”. That’s hardly a highly involved process.

    >in order to optimize for edge cases, you end up with a really horrible product in
    >the general case that’s only really useful for edge cases

    That’s quite an extraordinary claim considering that DVCS systems have achieved the lion’s share of version control. Nobody using them is complaining about them being horrible and certainly nobody’s abandoning them for Subversion. Again, people like Spolsky write guides that say things like “Here’s the part where you’re just going to have to take my word for it. Mercurial is better than Subversion. It is a better way of working on source code with a team. It is a better way of working on source code by yourself. It is just better.
    And, mark my words, if you understand the way Mercurial works, and you work the way Mercurial works, and you don’t try to fight it, and you don’t try to do things the old Subversion way using Mercurial but instead you learn to work the way Mercurial expects you to work, you will be happy, successful, and well-fed, and you’ll always be able to find the remote control to the TV.
    …Learn Mercurial, trust Mercurial, and figure out how to do things the Mercurial way, and you will move an entire generation ahead in source code control. While your competitors are busy taking a week to resolve all the merge conflicts they got when a vendor updated a library, you’re going to type hg merge and say to yourself, ‘Oh gosh, that’s cool, it just worked.’ ”
    Nobody of note is writing testimony about the horrors of DVCS and running to Subversion. In fact, in general, nobody’s arguing that old, outdated methods are superior to modern, advanced methods. Let’s not try to turn Delphi users into the Amish of developers.

    I think this video was created with you in mind 😉 :
    http://youtu.be/_yQlKEq-Ueg

  9. Thomas Vedel says:

    Hi Jim.

    I know the trick (editing the registry) when updating the SVN client.

    However, a lot of Delphi users doesn’t know this, and they believe that the SVN integration in the IDE gets lost forever, if the SVN client is updated.

    I suggest that an options setting is introduced in the IDE, enabling an easy way to change the path to the SVN client. It should be created when installing Delphi, and by default point to the standard collabnet SVN client location.

  10. Jim McKeeth says:

    Good suggestion Thomas!

    The merging with DVCS is so much more powerful and effective, it makes up for all the uncomfortableness that comes from changing systems and any perceived shortcoming.

  11. The merging with DVCS is so much more powerful and effective, it makes up for all the uncomfortableness that comes from changing systems and any perceived shortcoming.

    Sure, SVN merging really sucked 10 years ago, but it’s gotten far, far better now, since they revamped the system to track the metadata that it was missing. That’s not such a big advantage for DVCS these days, especially when the two most fundamental operations are still painful messes by design and that can’t really be fixed.

  12. Jim McKeeth says:

    SVN really sucked for merging 1 year ago.

    As Joseph pointed out, updating and committing are not significantly more complicated. After using Git for a while I actually find it significantly easier.

  13. OK, I’m lost here. What problems does SVN still have with merging? Because the only significant problem I’ve had with merging on a major VCS recently was every single freaking time I try to update a certain project that’s on HG and it doesn’t know how to automatically merge my uncommitted changes with the incoming ones the way SVN does, and requires me to hold its hand during the process.

  14. Thomas Vedel says:

    I simply don’t understand this “fight” around which VCS is better: Git or SVN (or any other VCS).

    I agree that a DSVN like Git offer new possibilities, but it demands that you have the additional ressources to manage the Git repository, and if you need to take advantage of Gits advanced features, you surely need some “education”.

    I think that the SVN integration that is already in the IDE is OK, except that it should be a simple task to update the SVN client software, instead of needing to edit registry entries.

    It would be nice if the IDE directly supported several VCS’s, so that you could use whatever system you prefer, but that’s not mandatory to me.

  15. dino says:

    I have a small Question. How does GIT/SVN handle the form merges and most importantly the Image lists and other non readable data in the forms? Are there any problems with this or does it go smoothly?

    Another question how does GIT handle large repositories (40 GB of code)?

Leave a Reply