I have never used a version control system before, and am rather confused about the very first steps. In a personal PIC/MPLAB programming project, under Linux, (no one else involved), with a single source code file that will go through several development stages as I add and verify features, I want to keep the set of "working so far" source code files, and Mercurial looks like a very good way to do it, preferable to my usual, and error prone, ad hoc approach.
So I have a very elementary question: I have installed Mercurial and accessed it from within MPLAB, and I have created a file
"/home/Harry/MPLABXProjects/flash675.X/.hg"
Please, I want to know 1) what to do next to start it off and 2) is it going to be obvious how I go about using the Mercurial system from then on? I find the documentation confusing on this very basic point.
(Yes, the first stage is just flash an LED, using a TMR0 interrupt, and that is working ok; I will then use that as a "prover" that the hardware is still working when I get to the inevitable "nothing happening" situations. I am building an ammeter for a p.s.u. with a Hall effect transducer, so I later will be adding an 8-LED serial display for debugging, a 12-bit A/D converter and a 4-digit 7-segment display, all using I2C serial control)
Good answer to this question will have the size of a full tutorial. There are many existing tutorials in the Internet, http://hginit.com/ for example. You can walk through it but I suggest to look at Mercurial: The Definitive Guide (link). The beginning of the book has a form of tutorial so it won't take a lot of time too.
The best helpers in learning is practice and experiments. Just don't forget to keep clean copy of your repository. It will save you when you break one of repository's clones. Here is a quick instruction so my answer won't be too philosophical.
Create your "prover". For example, it is a file called prover.c.
Look what you have: hg status. You will see your file with question mark. It means this file isn't under version control.
Add it to repository: hg add prover.c. Doing this you register your file in repository. After you commit Mercurial will start tracking changes in this file.
Commit: hd commit. You will be asked to enter a commit message. Good comments will help to discover a history in future.
That's it. If you change prover.c now and run hg status you will see that Mercurial knows about all changes. You can ask Mercurial to show changes by run hg diff.
I am trying to figure out how to use Git in a group (php programming) project. We need to be able to commit to the same project individually. I have read different things about git and realized that there are quite a lot of ways for achieving this.
My question is: What should I download and how do I set it up the best way? And how can this be used through eclipse?
Also, should the "GIT" folder/project be located online? If so, where should this be uploaded to?
(I have read that the git plugin for eclipse isn't the best solution at all)
The best solution is to read the EGit User Guide.
No need to read the whole thing, just come back to it whenever you're stuck in using it.
My team is currently in the situation that half the team is in Germany and the other half in the Netherlands.
We're using Mercurial as source control. The problem is that now that we are split up, because the way the company network works, it is not possible to connect our repositories together to do any pushing or pulling between them.
I was wondering if it is possible to somehow export a bunch of changesets, send it by mail or w/e and then import them on the other side?
I'm really new to Mercurial and distributed source control (previously I only worked with SVN really). But I understand that one of the differences is that it merges by reapplying all the changes instead of just looking at the difference between latest versions. That's why I thought that this might be possible.
Thanks in advance.
Yes, you can do this. See http://www.selenic.com/mercurial/hg.1.html#email
Edit: Use -b/--bundle to send multiple changesets as a bundle.
I've been working on an Xcode (iPhone) project with three different persons. We have the project on a Subversion repository, but we still don't completely understand some aspects of the Subversion + Xcode methodology:
1) Each time someone does a commit on a single file, it may appear or not in the project of the other developers. Even though the same person that creates the new files, it adds those files to the Repository and then it commits on those files. Why does that happens? Any suggestions?
2) Each person that is involved on the project can't do a "Commit entire project" without causing a considerable headache to the rest of the developers... any idea how this should be done?.
The working methodology that we are trying to implement is that only one developer (generally the leader of the project) can Commit the entire project but he must inform the rest of the team, so everybody can be prepared to receive a message asking him to discard his changes and read the new files from the repository.
I need suggestions or advice on how to handle a project with multiple developers using subversion.
We have read the Subversion handbook, and many other messages on StackOverflow but I still can't find any useful advice.
Thanks for any tip!
The reason the other guys are not seeing the changes is that they are not informed until they attempt to do an "update", "commit" or "diff" against the repository. SVN is a "pull" system, the repository doesn't inform the clients of anything without a command from them.
Communication is the key. If your developers are generally aware of what is going on in the project, or at least in their corner of the project if it's a large one, they'll minimize the risk of committing code that will upset the project.
Insisting that only one developer is allowed to commit to the repository is overkill IMHO and quite contrary to the whole idea of using version control. You might as well just have a single folder that only that developer can write to using a diffing tool each time.
Make sure your guys do an "Update", Compile, Test cycle before they "Commit". That way they are less likely to commit code that will break the build. If they're just a little careful, you'll all get the hang of it real quick, there really isn't that much to worry about. Good luck.
You are saying "The working methodology that we are trying to implement is that only one developer (generally the leader of the project) can Commit the entire project but he must inform the rest of the team, so everybody can be prepared to receive a message asking him to discard his changes and read the new files from the repository." Why is that needed? Are the other devs not able to checkin or not good enough to checkin code ? Sorry to say that in a drastic way: That's bull-shit. Every developer should be able to commit. If you like to separate the developers from each other you should use branches for this. And as already mentioned the communication is done by svn update/svn status -u etc.
After being told by at least 10 people on SO that version control was a good thing even if it's just me I now have a followup question.
What is the difference between all the different types of version control and is there a guide that anybody knows of for version control that's very simple and easy to understand?
We seem to be in the golden age of version control, with a ton of choices, all of which have their pros and cons.
Here are the ones I see most used:
svn - currently the most popular open source?
git - very hot since Linus switched to it
mercurial - some smart people I know swear by it
cvs - the one everybody is switching from
perforce - imho, the best features, but it's not open source. The two-user license is free, though.
visual sourcesafe - I'm not much in the Microsoft world, so I have no idea about this one, other than people like to rag on it as they rag on everything from Microsoft.
sccs - for historical interest we mention this, the great-grandaddy of many of the above
rcs - and the grandaddy of many of the above
My recommendation: you're safest with either git, svn or perforce, since a lot of people use them, they are cross platform, have good guis, you can buy books about them, etc.
Dont consider cvs, sccs, rcs, they are antique.
The nice thing is that, since your projects will be relatively small, you will be able to move your code to a new system once you're more experienced and decide you want to work with another system.
Eric Sink has a good overview of source control. There are also some existing questions here on SO.
To everyone just starting using version control:
Please do not use git (or hg or bzr) because of the hype
Use git (or hg or bzr) because they are better tools for managing source code than SVN.
I used SVN for a few years at work, and switched over to git 6 months ago. Without learning SVN first I would be totaly lost when it comes to using a DVCS.
For people just starting out with version control:
Start by downloading SVN
Learn why you need version control
Learn how to commit, checkout, branch
Learn why merging in SVN is such a pain
Then switch over to a DVCS and learn:
How to clone/branch/commit
How easy it is to merge your branches back (go branch crazy!)
How easy it is to rewrite commit history and keep your branchesup to date with the main line (git rebase -i, )
How to publish your changes so others can benefit
tldr; crowd:
Start with SVN and learn the basics, then graduate to a DVCS.
I would start with:
A Visual Guide to Version Control
Wikipedia
Then once you have read up on it, download and install SVN, TortoiseSVN and skim the first few chapters of the book and get started.
Version Control is essential to development, even if you're working by yourself because it protects you from yourself. If you make a mistake, it's a simple matter to rollback to a previous version of your code that you know works. This also frees you to explore and experiment with your code because you're free of having to worry about whether what you're doing is reversible or not. There are two major branches of Version Control Systems (VCS), Centralized and Distributed.
Centralized VCS are based on using a central server, where everyone "checks out" a project, works on it, and "commits" their changes back to the server for anybody else to use. The major Centralized VCS are CVS and SVN. Both have been heavily criticized because "merging" "branches" is extremely painful with them. [TODO: write explanation on what branches are and why merging is hard with CVS & SVN]
Distributed VCS let everyone have their own server, where you can "pull" changes from other people and "push" changes to a server. The most common Distributed VCS are Git and Mercurial. [TODO: write more on Distributed VCS]
If you're working on a project I heavily recommend using a distributed VCS. I recommend Git because it's blazingly fast, but is has been criticized as being too hard to use. If you don't mind using a commercial product BitKeeper is supposedly easy to use.
The answer to another question also applies here, most importantly
Jon Works said:
The most important thing about version control is:
JUST START USING IT
His answer goes into more detail, and I don't want to be accused of plaigerism so take a look.
The simple answer is, do you like Undo buttons? The answer is of course yes, because we as human being make mistakes all the time.
As programmers, its often the case though that it can take several hours of testing, code changes, overwrites, deletions, file moves and renames before we work out the method we are trying to use to fix a problem is entirely the wrong one and the code is more broken than when we started.
As such, Source Control is a massive Undo button to revert the code to an earlier time when the grass was green and the food plentiful. And not only that, because of how source control works, you can still keep a copy of your broken code, in case a few weeks down the line you want to refer to it again and cherry pick any good ideas that did come out of it.
I personally (though it could be called overkill) use a free Single user license version of Source Gear Fortress (which is their Vault source control product with bug tracking features). I find the UI really simple to use, it supports both the checkout > edit > checkin model and the edit > merge > commit model. It can be a little tricky to set up though, requiring you to run a local copy of ISS and SQL server. You might want to try a smaller program, like those recommended by other answers here. See what you like and what you can afford.
Mark said:
git - very hot since Linus switched to it
I just want to point out that Linus didn't switch to it, Linus wrote it.
If you are working by yourself in a Windows environment, then the single user license for SourceGear's Vault is free.
We use and like Mercurial. It follows a distributed model - it eliminates some of the sense of having to "check in" work. Mozilla has moved to Mercurial, which is a good sign that it's not going to go away any time soon. One con, in my opinion, is that there isn't a very good GUI for it. If you're comfortable with the command line, though, it's pretty handy.
Mercurial Documentation
Unofficial Manual
Just start using source control, no matter what type you use. What you use doesn't matter; it's the use of it that is important
Like everyone else, SC is really dependant on your needs, your budget, your environment, etc.
At its root, source control is designed to provide a central repository of all your code, and track who did what to it when. There should be a complete history, and you can get products that do full changelogs, auditing, access control, and on and on...
Each product that is out there starts to shine (so to speak) when you start to look at how you want or need to incorporate SC into your environment (whether it's your personal code and documents or a large corporations). And as people use them, they discover that the tool has limitations, so people write new ones. SVN was born out of limitations that the creators saw with CVS. Linus wanted something better for the Linux kernel, so now we have git.
I would say start using one (something like SVN which is very popular and pretty easy to use) and see how it goes. As time progresses you may find that you need some other functionality, or need to interface with other systems, so you may need SourceSafe or another tool.
Source control is always important, and while you can get away with manually re-numbering versions of PSD files or something as you work on them, you're going to forget to run that batch script once or twice, or likely forget which number went with which change. That's where most of these SC tools can help (as long as you check-in/check-out).
See also this SO question:
Difference between GIT and CVS