A proposed Subversion vision and roadmap [LWN.net]

A proposed Subversion vision and roadmap

Posted Apr 3, 2010 17:29 UTC (Sat) by Kit (guest, #55925) [Link]

In my experience, I've found git was extremely simple to use if your requirements were fairly simple. On the other hand, I found SVN much harder to use and setup when dealing with tiny, entirely personal projects. With git, I could start out by just having the 'repository' hosted entirely within the actual project directory (i.e. no real setup), without needing to setup/use any other servers. And then, if I later change my mind, adding the project to gitorious with the full history was quite simple.

Probably the most complex aspect of git I've found is that the official tutorial I used (primarily as a cheat sheet to help me remember the commands) seemed to keep moving locations on the kernel.org server.

A proposed Subversion vision and roadmap

Posted Apr 3, 2010 19:29 UTC (Sat) by fperrin (guest, #61941) [Link]

> On the other hand, I found SVN much harder to use and setup when dealing
> with tiny, entirely personal projects.

mkdir SVN && svnadmin create SVN && svn co SVN .
svn add *.c

Yes, that's more work than git init && git add *.c, but "much harder" ?

A proposed Subversion vision and roadmap

Posted Apr 3, 2010 21:37 UTC (Sat) by heipei (guest, #63821) [Link]

You don't seem to be using git the way I do. Let me give a little example:

1. Download some non-versioned source from a website, untar it into dir
2. cd dir; git init; git add .; git commit -m 'initial'
3. work, hack, commit, etc
4. decide that I don't want the history and just rm -rf .git (or the whole dir)

The point is that you don't have two locations for one tiny thing (a repo and a working copy). Also it
works in-place, whereas you have to create the repo with SVN, then checkout the _empty_ repo into
another dir, and then manually copy your files there to add and commit them. Still sounds equally
simple?

By the way, if you just want to keep track of very simple changes to a pristine codebase, you can
omit the "commit" in step 2. and just diff against the index. Another tiny thing: Your example
doesn't work (for me), since SVN is too stupid to recognize files without file:/// prepended.

Offtopic svn tricks (was: A proposed Subversion vision and roadmap)

Posted Apr 4, 2010 1:24 UTC (Sun) by cesarb (subscriber, #6266) [Link]

You do not need to copy your files to the empty working copy, you can just _move_ the hidden .svn directory from the empty working copy to where you are already working and rmdir the now-empty directory. Then just add and commit as usual.

Offtopic svn tricks (was: A proposed Subversion vision and roadmap)

Posted Apr 4, 2010 7:35 UTC (Sun) by fperrin (guest, #61941) [Link]

cesarb:
> You do not need to copy your files to the empty working copy, you can just _move_ the
> hidden .svn directory from the empty working copy to where you are already working and
> rmdir the now-empty directory.

Or even simpler, as I did in my exemple, just "svn co file:///$PWD/SVN ." while being in the
directory where you just untar'd the original source. (Or use emacs and `vc-create-repo'.)

heipei:
>Another tiny thing: Your example doesn't work (for me), since SVN is too stupid to
> recognize files without file:/// prepended.

Yep, I forgot about that. As I did above, replace the checkout step with "svn co file:///$PWD/SVN ."

A proposed Subversion vision and roadmap

Posted Apr 4, 2010 15:28 UTC (Sun) by drag (subscriber, #31333) [Link]

I have had zero experencies with source code control and I found Git much easier to use then anything else. I've tried SVN and CVS in the past, but they were just too difficult.

git init
git add .
git commit -a

boom, boom, and boom. Done.

I don't have to worry about renaming stuff, moving files around, moving directories around, deleting files, deleting directories, etc etc.. There is very little with git that prevents me from using a git repo as any other directory.

The only major problem I keep seeing people having with git is the lack of central repository.

It's very easy to have a central repository with git though... you just setup a repo, call it 'The Central Repository' in your mind and just commit and pull to it and never use it directly.

The biggest problems I've had with Git involved pushing from one repository to another that have been seperated for a long time. Having a 'central' git repo that is push/pull only solves that for me.

I still use the 'distributed' stuff since I will commit dozens a time a day while working online or offline, or behind firewalls, and on multiple disconnected machines.

Hell, I would not mind running a commit every time I do ":wq" on a vim session.

A proposed Subversion vision and roadmap

Posted Apr 5, 2010 4:32 UTC (Mon) by Kit (guest, #55925) [Link]

>I have had zero experencies with source code control and I
>found Git much easier to use then anything else. I've tried
>SVN and CVS in the past, but they were just too difficult.

This was exactly my experience. The (crappy) documentation I could find for SVN (I didn't bother with CVS, since it'd already been supplanted by SVN for a while by then) assumed I'd be using SSH or Apache to connect to the repository, and I found the SSH setup to be horribly ugly for a purely local workflow (I didn't even care to bother with Apache, that seemed a bit silly to me).

> boom, boom, and boom. Done.

Those commands are more than enough to get you started on a personal project, and it's fairly simple to pick up the other stuff as your needs expand (I was shocked at how simple branching was... I actually thought I had done it wrong since I'd read so much about how poorly SVN handles it). Plus, being able to make commits even when offline or when you don't want to make them public yet (but you don't want one massive commit containing a crap load of work all over the code base) is easy as hell with git (you just commit and don't push!).