We are working on a group project written in MatLab. We all need to be able to access and write the same program, sometime simultaneously. We are working on a scientific Linux distribution. We are all physicists so we would rather find a very simple - ideally GUI, solution.
It sounds like GitHub would enable us to write simultaneously and merge mismatched code but it seems so complicated. We don't really understand the push/pull/fork/commit terminology and we would rather not study it if there is an easier option.
What is the path of least resistance for a group project in Matlab?
I regularly use Subversion for group MATLAB projects. It has what I find a slightly simpler workflow than Git/GitHub.
The latest versions of MATLAB integrate directly with Subversion, so you can check things in and out directly from within the MATLAB workspace. Alternatively you can use TortoiseSVN, which integrates within Windows Explorer (I believe there is an equivalent for Linux as well).
However, I'll speak bluntly - Git and GitHub are really not that hard, and I'm pretty sure that anyone who's clever enough to be a physicist working with MATLAB is clever enough to understand them as well. Although Subversion is a bit simpler to learn, Git and GitHub have a lot of advantages, they integrate well with many other services, and they're just overall kind of better. The latest versions of MATLAB integrate directly with them in the same way as with Subversion.
Related
Myself, I'd be perfectly happy with Git or Mercurial, but I'm tying to identify a version control system which all our Windows admins could use for sharing script code, meeting the following requirements:
distributed, i.e. we want a central repository where users can clone or fork from
GUI on Windows (bonus points for Explorer integration like the TortoiseCVS forks)
Windows-friendly installation (e.g. msysgit's OpenSSH or PuTTY configuration disqualifies it)
easy to understand, i.e. the end users probably do not know or use terms like trunk, branch, and tag, and ideally would never need to
integrates with popular text/code editors like Notepad++ (this is not a must-have, but would be a real plus)
Maybe I'm asking too much, but there must be some usable VCS out there to fit the bill!
Some thinking
I can't see any strong reasons in your use-case for DVCS (i.e. reasons for cloning-merging instead of personal "shelves")
Friendly installation: for admins (even Windows-admins must have brain and easy understand "OpenSSH or PuTTY configuration")?
Ideas
You can see at Smart* products from Syntevo (Full-size GUI, not pure shell-extensions /but have shell-extension also/). Beware - Java! SmartGit have human-brain-friendly config, early versions also have support for Mercurial
For editors with SCM-integration I can suggest EditPlus (not free, but reasonable good price) - support from a box for basic Subversion commands (in a main menu), latest build have added support for TortoiseGit. But - with the help of UserTools virtually any (CLI?) command can be added to EditPlus interface and executed in EditPlus editor-window
I'm not aware of any non-IDE editors on windows other than maybe Emacs and UltraEdit that have version control support. Otherwise, Mercurial really does fill the bill. It's distributed, it has TortoiseHg, it has several options for windows installers (including admin and non-admin installs), and at least when using TortoiseHg, it's relatively easy to understand.
No VCS in the world is going to completely insulate users from its own concepts, but if you don't use branches and tags, the issue isn't going to come up (personally I'd recommend at least learning about tags -- they're easier to work with than raw rev spec hashes). Were you to find some other VCS that isn't one of these mainstream choices, I'd be interested in knowing about it, but chances are you'd also find it was one or more of a) expensive, b) has a vanishingly small community, and c) no sites like sourceforge, google code, or bitbucket to host your projects.
Now for one major alternative: If your users are primarily editing documents, then possibly you want a CMS of some sort, for which you have options ranging from the likes of Drupal, Joomla, and Magnolia, to something simpler like a Wiki. MediaWiki with some syntax hilighting plugins might be just the thing for single-file scripts. This is a centralized solution without any real editor integration however, so I'm not sure it's the workflow you're looking for. There are some wikis based on DVCS's (mostly git) but I find they tend to be the worst of both worlds.
I'm currently working on a project that's been going on for several years straight. The development-team is small (less than 5 programmers), and source-control is virtually non-existent, and the deployment-process as is is just based on manually moving files from one server to another. The project is in classic ASP, so building isn't an issue, as both deployment and testing is just about getting the files to where they need to be and directing the browser at the correct location. Currently all development is done on a network-drive which is also the test-server. The test-server is only available when inside the the local network (can be accessed trough vpn), and is available on the address 'site.test' in the browser (requires editing to the hosts-file on all the clients, but since there are so few of us that hasn't proven to be any problem at all). All development is done in visual studio. Whenever a file is change the developer that changed the file is required to write the file he changed into a word-document and include a small description as of what was changed and why. Then, whenever there's supposed to be a version-bump (deployment), our lead-developer goes trough the word-document and copies every file (file by file) that has changed over to the production-server. Now, I don't think I need to tell you that this method is very error prone (a developer might for instance forget to add that he changed some dependency, and that might cause problems when deployed), and there's a lot of work involved with deploying.
And here comes the main question. I've been asked by the lead developer to use some time and see if I can come up with a simple solution that can simplify and automate the "version-control" and the deployment. Now, the important thing is that it's as easy as posible to use for the developers. Two of the existing developers have worked with computers for a long time, and are pretty stuck up in their routines, so for instance changing it into something like git bash wouldn't work at all. Don't get me wrong, I love git, but the first time one of them got a merge-conflict they wouldn't know what to do at all. Also, it would be ideal to change to a more distributed development-process where the developers wouldn't need to be logged into vpn (or need internet at all) to develop, and the changes they made offline could be synced up when they were done with them. Now, I've looked at Teem Development Server from Microsoft because of it's strong integration with Visual Studio. As far as I've tested it seems possible to make Visual Studio prompt the user if they want to check in changes whenever the user closes Visual Studio. Now, using TFS for source-control would probably eliminate most of the problems with the development, but how about deployment? Not to mention versioning? As far as I've understood (I've only looked briefly at TFS), TFS has a running number for every check-in, but is it possible to tell TFS that this check-in should be version 2.0.1 of the system (for example), and then have it deploy it to the web-server? And another problem, the whole solution consists of about 10 directories with hundreds of files in, though the system itself (without images and such) is only 5 directories, and only these 5 should be deployed to the server, is this possible to automate?
I know there's a lot of questions here, but what is most important is that I want to automate the development process (not the coding, but the managing of the code), and the deployment process, and I want to make it as simple as possible to use. I don't care if the setup is a bit of work, cause I got enough time at hand to setup whatever system that fits our needs, but the other devs should not have to do a lot of setup. If all of the machines that should use the system needs to be setup once, that's no problem at all, cause I can do that, but there shouldn't bee any need to do config and setups as we go.
Now, do any of you have any suggestions to what systems to use/how to use them, in order to simplify the described processes above? I've worked with several types of scm-systems before (GIT, HG and SubVersion), but I don't have any experience with build-systems at all (if that is needed). Articles, and discussion on how to efficiently setup systems like this would be greatly appreciated. In advance, thanks.
This is pretty subjective territory, but I think you need to get some easy wins first. The developers who are "stuck up in there ways" are the main roadblock here. They are going to see change as disruptive and not worth it. You need to slowly and carefully go for the easy wins.
First, TFS is probably not going to be a good choice. It's expensive, heavy, and the source control in TFS is pretty lousy. Go for Subversion: it's easy to setup and easy to use, and it's free. Get that in place first, and get the devs using it. Much easier said than done.
Later (possibly much later), once the devs are using it and couldn't imagine life without a VCS, then you could switch to Hg or Git if you need first class branching and all those other nice features.
Once you have Subversion in place, you can use something like JetBrains TeamCity or Jenkins, both of which are free and easy to use. However, I'm just assuming you don't have a lot of tests and build scripts that the CI server is really going to be running, so it's far more important that you get VCS first. In all things: keep it as simple as possible. Baby steps. Get some wins, build trust, repeat.
I can't even begin to think where to begin with this! Intending no offense directed at you, apart from the mention of git and HG, this post could have been written 10 years ago.
1) Source control - How can a team of developers possibly work effectively without some form of source control? Hell, even if it's Visual Source Safe (* shudder *) at least it would be something. You have to insist that the team implement source control. You know what's available so I won't get into preaching about that. (However, Subversion with TortoiseSVN has worked quite well for me.)
2)
"write the file he changed into a
word-document and include a small
description as of what was changed and
why"
You have got to be kidding... What happens if two developers change the same file? Does the lead then have to manually merge two changes that s/he extracts from the word doc? Please see #1 and explain to them how commit comments work.
Since your don't really need to "build" (i.e. compiled, etc.) anything, you should be able to solve most of your problems with some simple tools. First and foremost you need to use a source control solution. Yes, the developers would have to learn how to use another tool (EEEK!). You could do the initial leg work of getting the code into the repository. If you have file access to the other developers machines, you could even copy a checked-out working copy to their machines so they wouldn't have to do the checkout themselves (not really that hard). You could then use all the creamy goodness of version control to create version branches when each deployment needs to be done. You could write simple scripts using the command line SVN tools to check out said branches and automatically copy the files to the target server(s). Using a tool like BeyondCompare, the copy process could be restricted to only the files that are different (plus BC can handle an FTP target if that is an issue). By enforcing commit comments on the SVN repo, you'll guarantee that the developers provide comments, and for each set of changes between releases you could very easily generate a list of all those comments using the CSM log retrieval features.
Does anyone know of a built-in way to have Hudson keep track of how many files are changed, added or deleted in the source code repository in each build ? I'd like to plot the results in the same way that the JUnit test results graphs show the numbers of passing and failing tests for each build.
The Measurement Plots plugin and the Plot Plugin look like they might give me a starting point, but i'm wondering if there might be a more specific plugin or feature already available.
My SCM system is CVS, but I'd like a generic solution that would work with other SCM systems.
I don't believe there are any existing plugins that will do this directly.
If it doesn't need to be specifically tracked for each build (that is if you are really more interested in changes over time), then I would suggest setting up Sonar, which tracks daily changes from your builds and integrates fantastically with Hudson, or FishEye which connects directly to your SCM system.
But why not try to write the plugin for Hudson? Seems like the sort of thing that people might like to visualize as a per-build metric.
I think this question is more generic than specific to Hudson. You're probably going to have to write a little code by yourself. Unfortunately, I don't think any solution will be SCM agnostic because Hudson tends to use the SCM tools themselves to do the SCM bits.
I couldn't find any off-the-shelf solutions, so here's what I see would have to be done:
Find the SCM command that you are using (i.e., svn up, cvs -n).
Use wc -l or some other command to count the number of lines in output. This will give you an estimate to the number of changed/added/deleted files.
Parse the output if you want the names of individual files that have been added/changed/deleted.
Unfortunately, I don't think there's an SCM-agnostic way of doing this. Perhaps the best you could do is find a pure-Java CVS/SVN client implementation that you could modify to keep track of files as they come in from the SCM.
I am working on an academic research regarding some very long functions in the Linux kernel (link, link).
For that research, I would like to use some code flow visualization tool, that would be able to plot a graph in which each vertex is a decision point and each edge is a piece of code which runs in a consequent way.
Do you know of any good, open source project that can visualize C code?
Perhaps a tool like KCacheGrind would be of help. It generates call graphs based on actual calls and cannot pre-generate a call graph without actually running the program, which may not suit your needs, but then it again it may.
History flow's are very neat for changes/diff across multiple versions.
Codeplex has a project, Dependency Visualizer which does support C also.
Gprof2Dot can render oprofile, this would get you dynamic info also.
CodeViz also (static tool) would work.
If your using gcc, gcc-xml has an introspector plugin also todo this.
You appears to want to acquire a flowchart of C source code ("decisions", "code blocks").
Something like this C flowchart?
To do this correctly, esp. for Linux kernal code, I'd expect you to have to preprocess the code first to get rid of macros and conditionals. I would assume that GCC would construct such a graph internally and that you ought to be able to get your hands on that graph.
Doxygen does some amount of 'visualization',
but you need to work on the code a bit for it to be usable.
Another interesting thing to check would be lxr
Linux Cross Referencer is a software toolset for indexing and presenting source code repositories. LXR was initially targeted at the Linux source code, but has proved usable for a wide range of software projects. lxr.linux.no is currently running an experimental fork of the LXR software.
I can recommend Sourcetrail. Can work with a compile_commands.json. Not sure if it's still maintained, though. But it's foss and you can fork it!
So I want to get a project on a distributed version control system, such as mercurial, git, or bazaar. The catch is that I need the Windows support to be good, i.e. no instructions that start off with "install cygwin...". Now I've heard that git's Windows support is decent these days, but don't have any first hand experience. Also, it sounds like the bazaar team has an explicit goal of making it as multiplatform as possible.
Can I get any recommendations?
I use msys-git on windows every single day. Works fast and flawlessly.
Although the newer build has some problems with git-svn, this build (Git-1.5.5-preview20080413.exe) has a working git-svn.
There's a nice comparison between git, hg and bzr in this InfoQ article. They all have their strengths and weaknesses. You'll have to think about your project and your workflows and choose the best fit. The good news is that they're all fairly good.
At last I checked, the only thing you need for Mercurial is Python and to grab a binary package. If you find yourself with more time and want to fiddle / build it yourself, look here.
The only real drawback with HG is its idea of branching .. but for some people that's a major plus.
I like it because its intuitive, easy to install and works on anything that Python does. I don't think that all of the available plugins will work for you, but most should.
I've had the best luck with Bazaar, followed by Mercurial. Never could get Git to work correctly. A quick search shows that Git still requires clunky emulation layers like Cygwin/MSYS, and I can't find any integration tools like TortoiseBzr for Git.
With Mercurial in Windows, I had several minor issues (insensitive paths, symlinks, ). They were usually fixed eventually, but I felt that the same quality of testing was not applied to running on Windows as for the other platforms. Bazaar also had better documentation for integrating with native applications like Visual C.
EDIT: Perhaps add a "dvcs", "distrubutedversioncontrol", "distrubuted"
I've used Mercurial on Windows with no problems. You can use TortoiseHG or just use the command line. Mercurial does require Python, but that is easy to install in Windows as well.
Mercurial Binary Packages
I agree with basszero. I'm using mercurial under windows and it's as easy and reliable as it can get. My development team is spread over Europe (well Dublin and Vienna :-).
We use VPN to commit or sometime the built in webserver (hgserve). Both work fine with no problems out of the box.
Also diff3 open source tool works perfect with mercurial and TortoiseHG out of the box.
If you are concerned about an easy to use interface:
The bazaar folk now include TortoiseBzr in their windows binary package. That's got to be a pretty strong indicator that they think it is up to snuff. I don't know what the maturity/stability of TortoiseHg is, but there certainly isn't a decent GUI interface for git yet, and the MSYS git build still needs some work IMO.
If your team are comfortable with or prefer the command line, then either bazaar or mercurial would probably work well for you, and are both probably about the same in terms of learning curve. Git's learning curve is much higher. It is like the swiss-army knife that is almost wider than it is long, with all the little gadgets and do-dads in it and hanging off it, with the springs so tight that you occasionally slice a finger open trying to prise a blade out.
In my experience using GIT on windows is a major pain. But I have been using Fossil SCM for some time now, and I think it actually fits your needs exactly.
It also has a built in Ticket system and a Wiki. And the whole program is contained in 1 file and it works right out of the box.
I totally recommend it.
Here is a link to the site http://www.fossil-scm.org/
Remember, this site is self hosting, what that means is you are looking at the web interface to fossil it self, when you look at tickets and the wiki and documentation, you actually are using fossil.
But if your project has millions of lines of code and is a few gigabytes in size, you have to use GIT, there is no way around that problem.
Enjoy.