views:

345

answers:

6

Here's the deal: I just started a new job, and source control here is basically useless. All of the devs (about 10 guys) test their code in the same dev site, and there's no way to test a change other than commiting the change to SVN, and then it automatically gets updated in the dev site. (Let's not even start talking about the headaches when someone else breaks something, and you have to figure why your stuff is now not working....)

So instead of doing like Ctrl+S, and refreshing the browser to see my changes, you have to Ctrl+S, svn commit, refresh the page. Of course since everyone has to do this a million times every day, there's never any commit messages, so the svn history is useless.

Anyhow, since I'm the new guy, for now, for my own sanity, I want to use some other source control system locally, so that I can commit projects atomically, and be able to roll back easily.

Is it possible to use for example mercurial at the same time as svn? I would use svn basically to see my changes, and mercurial to keep track of my changes.

Any alternative ideas are welcome too. Thanks!

UPDATE-

Thanks for all the answers. Unfortunately, none really suit me in this situation. Maybe I didn't explain it right. I don't want sync between repos. What I need is to be able to have like two different repository checkouts living in the same place. So if I do svn status I'm comparing against the regular company repo. But if I do hg status I'm comparing against my own personal repo to help me stay sane. Thx guys

A: 

You could use git locally to manage your own changes, and then use git-svn to pull/push those changes to SVN. http://flavio.castelli.name/howto_use_git_with_svn

glenc
+2  A: 

You could use git, bazaar or mercurial along side of svn, though you would want to be sure that you exclude the .svn directories from your new scm, and vice versa so that they dont track each others meta data.

As far as IDE support, I know Eclipse will only let you have one active source control at a time. I am not sure about NetBeans or IntelliJ. In that case you could have the IDE control the svn and do yours from the command line.

Another option you might want to look into is branching with svn... could you not work from a branch locally and then merge into the common mainline as needed? That might just cause more pain.

Good luck and sorry to hear about your situation.

cjstehno
The way I understand the question this answers it perfectly. I understand that the svn commit is necessary to update the test site and commits to the 'private' version control are less frequent in order to contain useful chunks of changes. It gets tricky when you have to update from svn in order to commit to svn and then risk to mix foreign changes and your own in your hg commit. I know that it's possible in git and guess the same holds for hg and bzr.
Olaf
+2  A: 

git svn is your friend.

git svn clone repository_url
# edit 
git commit
# edit 
git commit
# send all your changes to remote svn
git svn dcommit
VitalieL
I understood that the proposed workflow Mr AJL had in mind would rather have more frequent commits to svn (in order to update the test system) than to git/hg/whatever (in order to keep a meaningful commit message history). git-svn works the other way round, e.g. you commit first to git and then batch-commit everything to svn with dcommit
Olaf
+2  A: 

The hgsubversion extension to mercurial allows you to use mercurial as a svn client in the same way git svn does.

hg clone svn+http://python-nose.googlecode.com/svn nose-hg

after that your pushes and pulls will automatically go to/from the remote svn server too.

Ry4an
+2  A: 

For Mercurial Stack Overflow has a guide which describes Subversion interaction choices in detail. There are three current methods: hg convert, hgsubversion, and hgsvn. See the guide for details.

(My own two cents is that hgsubversion doesn't handle all repositories properly but, when it does, handles them very smoothly. When it doesn't I've had some success with hgsvn.)

UPDATE:

You said:

"Thanks for all the answers. Unfortunately, none really suit me in this situation. Maybe I didn't explain it right. I don't want sync between repos. What I need is to be able to have like two different repository checkouts living in the same place. So if I do svn status I'm comparing against the regular company repo. But if I do hg status I'm comparing against my own personal repo to help me stay sane."

Ah, I see. In simplest terms, yes. but you probably don't want to. You can checkout from Subversion, manually copy over your .hg directory from your Mercurial tree, and run commands from each. You almost certainly want tosvn ignore the .hg* files and add **.svn to your .hgignore. But you don't really want to do this unless the checkout is not being edited by you other than to occasionally svn update or hg pull from the original repositories. If you are also doing edits you will make a mistake and you will end up with something checked in to one or the other repository that you didn't want there.

If I understand you correctly you would still benefit from using one of the Mercurial-Subversion bridges. You can for example quite easily with hgsubversion do hg status to compare with your local Mercurial repository, and hg svn status to compare to the remote Subversion repository. Even if you don't sync, and you just compare your files to one repository and the other, it's still much better to have a system that understands both, and won't spill unwanted state from one VCS into the other.

quark
A: 

You can use multiple VCSes in one working copy. I tested both bazaar and git in one working copy which was actually tracked with SVN (my then main VCS). So, I had a .svn, a .bzr and a .git directory in there. No trouble at all. Of course, smart ignore settings are needed.

jae