Okay, time to import this code into SVN. svn import, right? This should be easy!
svn import https://...../trunk/
Oh crap, that tried to import everything.
^C
Guess I’ll just set svn:ignore.
svn propset . svn:ignore svn propset svn:ignore . svn propedit svn:ignore svn propedit svn:ignore .
Okay. Can’t do that on a non checkout. Fine.
cd .. svn co https://...../trunk/ myproject.svn cd myproject.svn/ mv ../myproject/* .
Right, okay. Add some files now.
svn add . svn add * svn st
D’oh, forgot to ignore again.
svn reset -R . svn revert -R . svn st svn propedit svn:ignore . svn st svn add bootstrap.py buildout.cfg setup.py src/ README svn st svn ci
Crap. I forgot to ingore my .egg-info.
svn rm src/myproject.egg-info/ svn ci -am "Removed accidentally checked-in setuptools cruft." svn ci -m "Removed accidentally checked-in setuptools cruft." svn st
Hm. It’s still there.
svn st svn propedit svn:ignore . svn st svn propedit svn:ignore . svn st
Why. Won’t. You. Ignore. That. Directory!?
svn propedit svn:ignore . svn st ls src/ svn propedit svn:ignore . svn st
Oooooh, I have to ignore it in src!
svn propedit svn:ignore src/ svn st svn propedit svn:ignore . svn st svn ci -m "Updated svn:ingore"
WTF? Oh. Right.
svn up svn ci -m "Updated svn:ingore" svn st
(The above is taken, unedited except to change the name of the project, from my bash history.)
Comments:
svn:ignore is why I switched to git. I didn't want to tell svn to ignore .class/.pyc/.o/etc in every new subdirectory that I created. I just wanted one rule in one place, like .gitignore.
in ~/.subversion/config
in the [miscellany] section
set
global-ignores = *.o *.lo *.la .bzr .bzrignore .*.rej *.rej .*~ *~ *.egg-info .#* .DS_Store #*# *.pyc *.cache
and whatever else you want. Viola.
You can also 'auto' set props on files in the [auto-props] section.
cake.
So, when will the Django Project be taking Python's lead and switching to Mercurial? I'd love to see that happen.
Yep, would be nice to see django using mercurial.
I use Mercurial at work, and it's the only time I've preferred non-Python software when given a choice. Most notably, mercurial doesn't do branches - well, you can, but then you're stuck with them forever, so instead you create clones cluttering your filesystem (if someone knows something I don't, please let me know!).
In general, git gets out of my way and allows me to code without having to think ahead of time what I'm going to do with the vcs. This is very well-explained in "The Thing About Git": http://tomayko.com/writings...
I'm still sorta surprised the Django source is kept in Subversion – I'd also like to see it in Git or Mercurial instead. But does TracBrowser or whatever http://code.djangoproject.com uses for code browsing support either?
Just something to consider, SVN supports HTTP well which can be accessed through company proxies. I have been able to access HG repos, but have yet to get a BZR or GIT repo working.
@James Pearson
Since hg 1.1, it's acquired the "bookmarks" extension which gives it git-like local-only branches on top of the existing "full" hg branches.
At this point, the only actual differences between hg and git are hg's lack of "the index" and git's like of a sane CLI.
I'm quite new with Python, but I've decided to do a first thing for the community by writing a reusable app that allow to manage Mercurial repos through django. A sort of Trac but for Mercurial and the repo creation, the authentication process, etc., are done by django.
It's not production ready for now, but I'm quite impressed by the easyness of the developpement.
The code is available here for those who may be interested:
http://bitbucket.org/nautil...
(Yep, I know I should eat my own dog food but django_hg is not ready, even if the project is near in functionnality of Mercurial builtin webserver)
@Masklinn
Ooh, that looks very useful. It look, though, you still end up with multiple heads that will get pushed to the repository if you haven't merged changes back into the main. I find myself often needing to do a quick bugfix while I'm in the middle of doing something else, and if I did that with bookmarks, I'd still be creating a new head to the "blessed" repository.
I've seen a lot of examples of people being incredibly frustrated with git's UI, but for some reason, I've never had any problems with that. A large part of that is probably that hg was the only VCS I had used before that, and not incredibly heavily, so I didn't have any preconceptions on how things should work.
I suppose it's a similar thing to ruby vs. python - use which fits your brain better.
Horray for hg!
So, Jacob, you're essentially saying that because you don't know how to RTFM when you don't know how a CLI works, that CLI sucks?
I agree Subversion doesn't always make sense (propset being the most obvious mishap), but many of your mistakes are obviously because you're used to Git. And really, Git doesn't do these things any better.
No, .hgignore/.gitignore really do work Better than svn:ignores for setting up a project. Personally, I don't touch raw svn anymore unless I absolutely have to.
Yes, hg is much cleaner. As far as hg "not having branches", you should look at the bookmarks extension, it might do what you want.
Leave a comment: