For those of you who are interested, the source code repository for the JCL (JEDI Code Library) is now officially hosted on GitHub. The JEDI team also has a placeholder for the JVCL which will probably come some time later. The JCL is still hosted on SourceForge (in SVN) but from what I can see the GitHub repository already has a new commit ahead of the latest SourceForge repository.
For those of you who are interested, the source code repository for the JCL (JEDI Code Library) is now officially hosted on GitHub. The JEDI team also has a placeholder for the JVCL which will probably come some time later. The JCL is still hosted on SourceForge (in SVN) but from what I can see the GitHub repository already has a new commit ahead of the latest SourceForge repository.
Another interesting thing is the GitHub repository contains the full commit history of the JCL from its very beginning when it used to use JEDI VCS all the way through to CVS and to the very latest commits in the SVN repo. Whereas on SourceForge, the commit history is split between its original CVS repository and the subsequent SVN repository.
I hope more Delphi developers start to use Git and GitHub because once you get past the initial learning curve, it's fairly easy. One of the greatest features of GitHub is the "pull-request" which makes it very simple for individual developers to send their code contributions to open-source projects. Conversely, if you are the project maintainer, GitHub also makes it very easy for you to review and subsequently merge these pull-requests back into the main repository.
I hope this move to GitHub will encourage more Delphi developers to get involved with not only the JEDI projects but also other Delphi open-source projects that are hosted on GitHub.
https://github.com/project-jedi/jcl
Another interesting thing is the GitHub repository contains the full commit history of the JCL from its very beginning when it used to use JEDI VCS all the way through to CVS and to the very latest commits in the SVN repo. Whereas on SourceForge, the commit history is split between its original CVS repository and the subsequent SVN repository.
I hope more Delphi developers start to use Git and GitHub because once you get past the initial learning curve, it's fairly easy. One of the greatest features of GitHub is the "pull-request" which makes it very simple for individual developers to send their code contributions to open-source projects. Conversely, if you are the project maintainer, GitHub also makes it very easy for you to review and subsequently merge these pull-requests back into the main repository.
I hope this move to GitHub will encourage more Delphi developers to get involved with not only the JEDI projects but also other Delphi open-source projects that are hosted on GitHub.
https://github.com/project-jedi/jcl
Damn... Git is not very good for following the development, maybe for developers... Or is there a graphical tool that could be used from command line to get changes and show the log... The command line tool is really difficult for that... Or at for me at least...
ReplyDeleteI don't agree. Github is very userfriendly. See https://github.com/project-jedi/jcl/commits/master. For each commit you can see the changed files. And you can even comment each change for a file or even set comments on a specific line.
ReplyDeleteI grew up with the command line, and I really hate it.
ReplyDeleteIs there something Tortoise-like for Git?
Yes, Lars Fosdal: http://code.google.com/p/tortoisegit/
ReplyDeleteIsn't it ironic to hate the command line given that we, as programmer, spend most of our time typing text into an IDE?
ReplyDeleteTommi Prami Type gitk on the command line and it will launch a basic repository browser with a panel displaying a graphical view of commit branches and another panel displaying the content of the files of the highlighted commit. Of course there are other tools as mentioned by Ondrej Kelle such as tortoisegit which also does the job. Another git windows client that is very good is Git Extensions (http://code.google.com/p/gitextensions/)
ReplyDeleteWow. Quite the source tree. Everything and the kitchen sink too. I guess that's typical of a monolithic SVN migration, but it should really be broken-up into multiple repos and cleaned-up. I see a lot of non source files too, such as executables, zip files, PDFs, etc. I fully understand that this is a huge undertaking and appreciate the effort just to make the initial move to GitHub.
ReplyDeleteOne other suggestion might be to adopt the popular GitFlow branching model. You can search Google for many articles on GitFlow, but the "original" article can be found here http://nvie.com/posts/a-successful-git-branching-model/
From GitHub, you can also view the main JCL repo as well as any cloned JCL repositories from other contributors on GitHub from here: https://github.com/project-jedi/jcl/network
ReplyDeleteSVN (Subversion) was good for me. Why move ?
ReplyDeletePierre Duparte I'm sorry, but I find your comment totally confusing. Please elaborate, as you seem to imply that the move to GitHub is negative and somehow due to the shortcomings of modern programmers.
ReplyDeleteI recommend GitEextension (Windows). Displays all commits in a Histotry, you can search for specific commits, or display the history of a single file or go back in history for a single file and save this state to get it back. (I know, this features are part of git, but GitExtensions wraps them nicely)
ReplyDeleteA preview of the GitExtensions Gui:
ReplyDeletehttp://s14.directupload.net/images/130212/a87wywnm.png
In this cas ethe history is Linear. In case of merging and subbranching, it xtends to a subwaylikeplan :P
François Piette Using SVN on SourceForge works for me too. SVN made it easy for me to checkout the latest version of the JCL from the repository. As a consumer of the JCL it was perfect.
ReplyDeleteBut what is it like to be a producer of the JCL? How much effort does it take for me to contribute back code fixes, features and enhancements to the JCL? If I was a project maintainer, how much effort is required to accept and incorporate those changes back into the project?
Under the current regime, there is no easy way to contribute back to the JEDI projects via SVN unless you become a trusted member of the project and have commit rights directly to the repository - and in no sane society will that ever happen for your first time contributor. Your other option is to post your code
in the issue tracker (http://issuetracker.delphi-jedi.org/my_view_page.php) as a zip file or even in the description section. For the maintainer, there is a lot of manual copying/unzipping/diffing/reviewing and merging of files to make this a slow and painful process.
Git and GitHub use pull requests to make this process happen with less friction. Contributors can submit their git commits from their own cloned copy of the JCL repo to the JEDI project maintainers who can then immediately see the diffs, and can review and send feedback comments and ultimately merge the commits when they are happy - all within GitHub.
There will be teething problems as people learn this process but ultimately, GitHub via Git promotes a more collaborative and proactive approach to maintaining open source projects.
Not too convinced about github as a host, the site is often unaccessible and slow IME. I suppose they've grown too fast, and they seem to be encountering the same growth issues SourceForge did.
ReplyDeleteEric Grange I haven't noticed that to be the case, however, being able to commit changes to your local repository without requiring a connection to a host is certainly a nice advantage of a DVCS like Git. Not to mention no more horrible .svn folders polluting the source tree.
ReplyDeleteIt's interesting that the space taken by a git repository full of historical commits can be similar in size to a SVN repository with just the single HEAD checked out.
ReplyDeleteKevin Powick The .svn folders are no longer used in recent versions of Subversion.
ReplyDeleteKevin Powick Sure, but on the other hand, committing to googlecode svn is faster than committing to git locally IME, and local commits aren't that useful when you come down to it (no code backup, no code sharing), and can even be harmful when some devs go for days without sync'ing.
ReplyDeleteAs for github, I'm referring to the regular 404 errors for major projects on the web interface, and server not responding errors from git. Small projects don't seem to be as affected, but the more popular projects are very problematic from here (France). "DefinitelyTyped" is more miss than hit f.i., so the only saving grace is once you've been able to pull once, you don't need to pull again (or often), but that's not very reassuring as hosting goes.
Eric Grange I cannot comment on the speed difference between the two commit types, but if you're using SVN and working off-line, the point about speed is rather moot.
ReplyDeleteNobody should be relying on a remote host to backup their code, but working off-line with SVN is no less risky than working off-line with Git. Btw, you can easily share your Git repositories without a central host by using Git Daemon
Finally, hoarding commits has nothing to do with version control, but with people. Actually, it should be much less likely to happen with a DVCS in general because pulling the latest updates does not mean having to commit them immediately, locally. And with a setup like GitHub, the ones that control the project control which contributed commits are accepted into the source tree via the Pull Request mechanism. This allows participation from anyone without first having to become an approved/trusted committer. Add to this the ease with which branching and merging can be done and Git really shines.
I really started with source control with Perforce for a long time, then switched to SVN for a few years, but having discovered DVCS such as Git and Mercurial (my preference), I wouldn't go back.
Kevin Powick These days working offline is a rarity IME, if only because all the docs are online (this is especially true with Delphi, and even more so with a lot of other frameworks).
ReplyDelete>Nobody should be relying on a remote host to backup their code
Sorry, I don't follow. A backup on your HDD is not a backup at all, even if it's in a transactionnal DB. And I'm not referring just to hardware disaster, but also unintentional deletes, etc.
>hoarding commits has nothing to do with version control,
That's not my experience. The longer you can work without a centralized commit, the longer people tend to work without performing a central commit.
>pulling the latest updates does not mean having to commit them immediately
Not sure what you means, that's the case with all CVCS.
>This allows participation from anyone without first having to become
>an approved/trusted committer. Add to this the ease with which
>branching and merging can be done and Git really shines.
Yes, that's Git strong point.
My comment about backups was that you seemed to imply that an advantage of SVN was that code backup was implicit because of the requirement for a central server. Anyway, I'm sure we all agree that a good backup strategy is important.
ReplyDeleteI was writing counterpoints to your comments, and elaboration of mine, but we're just rehashing what many others have debated before. Personally, I'm convinced by the arguments that support DVCS and have found the switch away from SVN to Git and Mercurial worthwhile.
Is there a video tutorial for noobs in using Git?
ReplyDeleteGraeme Geldenhuys What GUI do you use for git? I've been using TortoiseGit for more than a year, but it's slower to make a local commit with git than a server one with TortoiseSVN (at least against both googlecode SVN and our LAN SVN server). Command line is not an option, I've been spoiled by Tortoise in its various incarnations to ever consider using command line again :P
ReplyDeletegitk doesn't seem to do anything, I suppose it needs something else to be registered that msysgit didn't register.
ReplyDeleteFor git gui, I guess I'm missing something, because getting anything done takes a lot of clicks, and the actions themselves didn't seem faster than with tortoise git, in comparison you can do common actions in tortoise git right from any explorer window in two clicks. Overall, it was much slower to commit a particular file or view a blame than in tortoise git, which itself is slower than tortoise svn.
Also git gui is partly localized, and there doesn't seem to be a way to turn off localization?
As for repositories, github seems to be the worse from here, minor github projects are okay, but the larger ones often give 404 errors on the website and connection errors with git.
I'm committing regularly to two remote svn (one google code, one private), a LAN svn, and for git github & bitbucket. LAN svn wins, followed by googlecode svn, followed by git local commits (I would have expected it to be at least as good as the LAN, but it's not).
For instance the last git sync I did to bitbucket, with nothing to push and nothing to pull took 8 seconds...
Success (7953 ms @ 15/02/2013 17:48:42)
On the same source repository but under googlecode svn (minus a hundred files out of several thousandths), the same sync takes slightly less than 2 seconds. LAN svn (on a larger repository than both) is instantaneous.
And I'm seeing similar ratios for blame, revision graphs and diffs.
Judging by the logs Git seems to be spending most its extra time compressing when committing and decompressing when doing blame. SVN approach commits are more brute force, but Internet and LAN access is fast, so that's no issue (except with github). Blame and other logs are cached locally with recent SVN versions, so the explanation could be that their cache is more efficient than git's, which seems to be reapplying the diffs each time.
ReplyDeleteWhen pushing/pulling, git log claims to transmit very few data, but there is a significant latency between packets.
I got gitk to work, but only from the bash shell, apparently it's not properly integrated in Windows or Explorer.
Eric Grange When I installed msysgit, the installation wizard offered to add gitgui and git bash to windows explorer. From explorer, I just right-click the folder which contains the git repo and select git gui and/or git bash.
ReplyDeleteFrom within gitgui, there is a menu option to display branches which launches gitk for the repo.
Apparently I'm not the only one with git performance issues under Windows, I've found several StackOverflow posts on the subject, and dozens of recipes, ranging from uninstall-restart-reinstall to setting various options or even running everything as root (this coming from Linuxians). I'll have a go at some of them, because at the moment git is clearly very very slow.
ReplyDeleteAfter uninstall/reboot/reinstall and going from 1.7.10 to 1.8.1.2, git operations went from 7-8 seconds to 3-4 seconds, so that's twice faster, but not quite enough to come on top. On the same source base SVN operations with googlecode are around 2 secs, and LAN SVN is instantaneous.
ReplyDeleteThe repository in question has 2700 files, for about 35 MB, how much time do you see on your end when pushing/pulling with something similarly sized?
The size was 35MB total for all files, the times were for a push with no local changes, and a pull with no remote changes, so no data transmitted over the network beyond the hash IIUC. Average times are a consistent 3-4 seconds for an empty pull.
ReplyDeleteSomething's still wrong here, as soon as I push something, even a small file with only one line changed, it takes 8-9 seconds. A push for half-dozen of small files (less than 10 lines each) took 28 seconds. Simple local commits are rarely below 1-2 seconds. I've actually taken the habit of moving to something else while git is doing its stuff :/
ReplyDeleteAnti-virus inspection?
ReplyDelete