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.
This explains a conflict while working with Subversion:
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.
Posted by Martin Konicek
on 10:46 PM
18 comments:
Great Job! This will be very helpful when I'm teaching new users.
Thanks! I wish you good luck with teaching.
Hi, nice tutorial !
May i ask how you produced it, wich tools?
Cheers, keep up with the cool work.
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).
Really useful, thanks!!
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.
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/
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.
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!
@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"?
few pics which worth a thousand words...
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)
Very beautiful, thanks!
But where is MERGE?
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.
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).
Thanx a lot!
great job....
Post a Comment