Subversion visually explained in 30 sec - svn tutorial

This video tutorial tries to explain the basics of how SVN is used. The buttons at the bottom are movie controls. Scroll down for conflict explanation.

svn.swf



This explains a conflict while working with Subversion:

svn_conflict.swf


Summary of SVN commands (do these commands with TortoiseSVN by right clicking on a file or directory):

  • SVN checkout

    The first command to use Subversion. Downloads repository contents to a folder on your PC, makes this folder special SVN folder with SVN icon.
  • Update

    Merges new changes from repository to your working copy. Update before every commit is important because of possible conflicts, that must be resolved by conversation with your teammate, because concurrent changes cannot be resolved automatically.
  • Commit

    Megres changes from your yorking copy to SVN repository.
  • Resolved

    Tells SVN that the conflicted file is now OK.
  • Add

    Schedules new file to be saved to repository with next commit.
  • Delete

    Shedules file to be deleted from repository with next commit. SVN keeps all history, so accidental deletes are not a problem.
  • Revert

    Undoes all changes to your working copy since last commit. Usefull if you really mess up and want to throw away the changes and start over.
  • Log

    Shows nice log of changes sorted by date, even with simple statistics.

kick it on DotNetKicks.com

Posted by Martin Konicek on 10:46 PM

18 comments:

Jason Young said...

Great Job! This will be very helpful when I'm teaching new users.

Martin Konicek said...

Thanks! I wish you good luck with teaching.

Unknown said...

Hi, nice tutorial !
May i ask how you produced it, wich tools?
Cheers, keep up with the cool work.

Martin Konicek said...

Hi, thanks. I produced it in Flash. The pictures of server and user are from http://www.iconarchive.com/ . I changed the color of coder B's T-shirt in Photoshop using Magic Wand for selection and then Image->Adjustments->Hue/Saturation (changing Hue).

Anonymous said...

Really useful, thanks!!

KC Baltz said...

Nice demo. I may use this in the future to teach others.

Once criticism: I liked it up to the last line of text, "Changes are merged in the Repository". Maybe it's a translation issue, but I think there's the potential for confusion. When I teach users about conflict resolution in CVS/SVN, I always tell them that changes are merged on their computer. The merge happens when you do update, not commit, because whatever you have in your local version when you commit is exactly what ends up in the repository. That's why CVS/SVN forces you to update before committing. I think you should add a few bubbles.

1) When user A calls svn.update, say "No changes to A's copy of the file".

2) When user B calls svn.update, say, "User B get's A's changes in his file".

3) When user B calls svn.commit, say "The merged file is committed to the repository.

Unknown said...

This "tutorial" sucks! The developers should be of course working on their own branches and do proper merging from their branches into the "main" branch. And - avoid svn if you can, there are plenty of
better VCS like for example: http://bazaar-vcs.org/

Martin Konicek said...

KC Baltz, thanks for feedback! I meant "The changes are merged and commited in the repository." I will try to make it clearer.
1.) and 2.) should be visible from the red circles, but bubbles as you suggest could make it more obvious.

Martin Konicek said...

Hacklberry, based on my personal experience, one branch per developer is not a common scenario. About distibuted VCS.. I've seen a small team switch from SVN to Mercurial - it only added complexity, they don't report any benefits. Btw, for SVN exists a free graphical client TortoiseSVN so that I never have to touch console, and a free plugin for Visual Studio (Ankh) - both rock!

Unknown said...

@inv: "based on my personal experience, one branch per developer is
not a common scenario" well no offence but it means that your personal
experience is not that good and it explains why many projects that use
"common scenario" have problems. You do want a separate branch for
every changeset (changeset represents for example a bugfix or a new
feature). That way you can separate different changesets. Let's say
that you want to add in next few weeks 3 new features A, B, C to your
project/application. If you are going to do them all on one branch
TRUNK you end up with something (chaotic) like this:

TRUNK-a-a-b-a-b-c-a-c-b-b-a-c-c-b-a

(where a,b,c represent concurrent checkins belonging to those 3 new
features A, B, C), you start testing them and you discover that there
are 4 bugs - how are you going to tell who and when introduced a bug,
or which feature is buggy?
you are going to spend a lot of time to find that out the hard way, as
you decided not to use the tool (svn) properly.
but look what happens if you use separate branches:

A-a-a-a-a-a-a
B-b-b-b-b-b
C-c-c-c-c

first benefit is obvious straightaway - you can test each feature
separately. now you can start merging them one by one into the TRUNK:

TRUNK-A (merge, test)
TRUNK-A-B (merge, test)
TRUNK-A-B-C (merge, test)

now we see another obvious benefit if one of our features A, B, C has
some problem (bug-s, or for whatever reason is not ready to be added
to the TRUNK) we can easily remove it and integrate it later, for
example:

TRUNK-A (merge, test) ... ok
TRUNK-A-B (merge, test) ... bug! leave B out for now
TRUNK-A-C (merge, test) ... ok

fix B and merge it into TRUNK later:
TRUNK-A-C-B (merge, test) ... ok

you gave up on all these nice features! why?

"I've seen a small team switch from SVN to Mercurial - it only added
complexity, they don't report any benefits." - well that does not
make much sense because one could use hg,bzr,git pretty much the
same way like you use now svn:
svn stat - bzr stat
svn add - bzr add
svn ci - bzr ci
svn log - bzr log
...

and some commands in modern RCS (not svn) work properly for example
'bzr move' really moves objects (won't get fooled even if you change
file names), while svn doesn't really move it makes copy+del.

Therefore I wonder if you could explain how migration from svn
to hg "added complexity"?

moments said...

few pics which worth a thousand words...

Martin Konicek said...

hi hacklberry, sorry for writing late..
Branches per feature a probably a good thing. In the tutorial, the users are not working on different "features" though. You might argue that everything anyone does is a "feature" but that would be getting philosophical. Believe it or not, we (just 2 people team) haven't used branches on our project and we don't have any problems, as you describe. Everything is absolutely fine.
About hg: it became much more complex to explain it to everyone, especially VCS newcommers. There is working copy, local repository, and some other repository. There is (by default) no "main" repository. There are commands for moving stuff between local repository and working copy. Another set of commands is for moving stuff between local repository and "main" repository. Other user can "pull" from you if you "serve". That's the complexity I meant. The user just has to understand the concept of commit, send, branch, merge (+ serve, pull). SVN is just update, commit. MAYBE it can be used almost the same way as SVN, but then what is the point in not using SVN? (okay bzr it can move objects, which is nice).

And - two things that you ignored:

GUI client TortoiseSVN integrated with windows explorer (yes I dont't really ever touch a console! This matters a lot to some people),

and

Visual Studio plugin Ankh that does SVN rename while you rename files in the IDE etc. (which totally matters to those tons of VS developers out there!)
Hg has TortoiseHg recently (not sure bzr does have Windows GUI)

gK said...

Very beautiful, thanks!

Anonymous said...

But where is MERGE?

Bucky said...

This was a perfect 'get me started' overview on what SVN does. I've been reading some stuff that was making very little sense. This pointed me in the right direction. Thanks.

Martin Konicek said...

MERGE is the UPDATE.

@hacklberry (after a long time): I realized that distributed version control with easy branches (hg, git) really makes a lot of sense and it is better than the SVN model, mainly because branches in SVN are so badly designed (one local copy of all the code per branch).

Anonymous said...

Thanx a lot!

Post a Comment