One of the most annoying things about creating new SVN projects is the new project dance:
$ svnadmin create $SVNREP_DIR/newproject
$ svn mkdir -m "layout creation" file:///$SVNREP_DIR/newproject/trunk file:///$SVNREP_DIR/newproject/tags file:///$SVNREP_DIR/newproject/branches
$ mkdir newproject
$ cd newproject
$ svn import -m "initial import" . file:///$SVNREP_DIR/newproject/trunk
Oh... yeah, no this isn't that bad.
It's this part that's bad:
$ cd ..
$ mv newproject newproject.tmp
$ svn co file:///$SVNREP_DIR/newproject/trunk newproject
$ # do sanity check here...
$ rm -rf newproject.tmp
That's a lot of work, and it's actually hard to remember unless you do it a lot.
Here's the mercurial equivalent:
$ mkdir -p newproject/trunk
$ cd newproject
$ mkdir branches tags
$ hg init
That's it. It's not apples to apples of course. Mercurial keeps its repository locally, and does very simple push/pull commands for synchronization. But the dreaded dance of removing a project after it's been imported and then checking out the project is really a peeve of mine.
This is brain damage that svn inherited from cvs. I’ve wondered why every svn user hasn’t complained loudly about this “feature”.
You’ve probably noticed that graphical tools like Subclipse don’t have this problem. The Team -> Share Project menu item checks your project in and leaves you with a working copy. The svn team should have included a command to do this too.
I asked Mark Phippard about this and the sequence of commands that Subclipse uses to do a check in and get a working copy is below. These are from some old notes of mine, so be sure to back up your project before trying this in case I made an error.
svn mkdir -m “Add new project dir to repos” newprojectdirinrepos_url
cd new_project
ls -a // shows no .svn directory
// now check out the empty repository directory into your project svn co newprojectdirinrepos_url .
ls -a // now shows a .svn dir
svn add –force .
svn ci -m “Initial import”
I don’t know why the last step is a check-in instead of a commit.
I also don’t know why the svn FAQ and svn Redbook don’t include this. It would save a lot of aggravation.
Nice post
Note that having a toplevel “trunk” with “branches” and “tags” in the same level is an svn convention that has grown out of the way subversion represents different branches by different repository subdirectories.
You don’t really need those in Hg, because whenever you want to “fork” the tree and start heading in a slightly different direction (a branch), you can clone the original:
% cd projects % hg clone foo-devel foo-1.0 % cd foo-1.0 % hack ; commit ; hack more ; commit moreDean,
Yeah, I suppose a simple shell command could automate the process, but it should be part of SVN.
Giorgos,
SVN was my intro into version control, so conventions likee branches tags etc are still stuck with me, but I like the idea of “clone”. I’m glad I posted this, I end up learning more from comments
Hi.
I’m a casual user of SVN, never tried Hg. I tend to agree with you. The more common way of people doing things is to start a project in their own machines and only when they think they have something worth keeping do they about creating a repository in SVN. So it’s almost certain that you’ll be repeating those old steps from the irritating new project dance. Bloody annoying if you ask me!
Cheers
Paulo