I have a severe problem with my mercurial repository and I do not know what I have done wrong.
I am using the MercurialEclipse Addon for Java development on a local repository. Some time ago, I created some branches for better organization.
When I then looked at the graph in TortoiseHg, it looked kind of wrong to me.
As I know, the graph of the main branch should always be at the left side. But in my case, it is shown somewhere else.
What have I done wrong? Commit error? Or do I understand the graph wrong and everything is correct?
The left side are the parents of your current revision, with everything being in commit order (kind of sorted by date).
Well, if this isn't the standard, it's pretty common.
The default branch is not the main branch for everyone, as there is many ways to organize the code.
Disclaimer: I am a Mercurial noob with a shallow background in CVS. I have searched quite a bit and can't seem to find a clear answer, so here it goes. I am attempting to work out a simple default-stable named branch work flow in Mercurial. I understand that when you tag a change set, the act of tagging is itself a change and is committed. Let's say I am here:
I got here by running
hg update 0.1.0_Beta
fixing a bug, and committing the fix.
Scenarios:
I did something wrong
Q: What did I do wrong / What should I have done?
Right so far...
Q: What do I do now?
You're in great shape. There's nothing you need to do. Tags are automatically "read" from all 'heads' so there's no need to merge the head on stable that creates the tag (4c84...) into anything else. When you do hg stable you'll get acf8... and when you do hg update default you'll get 3449..... Rock on.
After experimenting a bit, it seems like I didn't really do anything wrong, and that merging the two heads is the right way to continue. I think that the single floating change set just sort of threw me off looking at it. If the bugfix is in the last stable change then updating to the tip of stable might make sense. I am still unsure of whether or not it is worth it to fix bugs deeper in the history unless there is a specific need to (customer support or what-have-you). I'm going to accept this answer unless someone else leads me to something better.
I have a few CVS WCs and, today, I took a look at one to make sure such-and-such code was present, but before I tell my colleague that it's okay, I need to make sure I'm looking at the right branch.
Somewhere I read that cvs log is the right way to go, so I cvs log [filename] and it listed all the branches in the project, but I wasn't sure how to see which branch I was using at the moment.
You want to do a cvs status and look at the Sticky Tag: line. there should be a branch listed in parentheses.
Sorry, I can't capture the output for you, thankfully it's been almost a decade since I touched CVS.
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