Tip:
Highlight text to annotate it
X
Hello everyone!
This is Zathrus Writer and you are watching the ninth episode of our programming series,
featuring Eclipse Software Development Kit. There was quite a bit of movement and stagnation
present in the past few months, preventing me from creating new videos and bringing
some interesting news to the Eclipse community as well.
You might have noticed the first of the changes already as you started watching this video.
I have temporarily moved from the oldie but goldie
Eclipse Indigo to the new and cool Eclipse Kepler. It's been a while since I tried this
and I have decided to give it a try once again to see if it's still
as bug-packed as its predecessors - at least on my computer.
If this version brings me happiness, I will stick with it. If not, I'll revert back to
the oldie goldie.
As a result, I have also updated the previous SVN episode with information about what to
expect when installing Subversive in Kepler or even how that's actually done. I might
do a full episode, highlighting the pros and cons of this new Eclipse version - so if you're
interested, just drop me a note and I'll see what I can
do.
In other news, Aptana Studio unfortunately seems to has gone completely dead. Their last
tweet is dated nearly 2 years ago and there was no new version,
nor an answer from their support to me since. In the light of these circumstances I'm preparing
to change Aptana for something else - which will be quite
a pain, given the greatness Aptana guys brought to us in the last decade.
But enough small talk, let's fulfil what I promised in the last video. We will be talking
about trunk, branches and tags in SVN, what they are used for
and how did I experience using them in a real production environment myself.
First of all, we'll look into how to use tags. For this, let's strip our Age Calculator of
its JavaScript capabilities and leave just a simple HTML,
CSS and PHP in the project. Let's call this version 1 of the product and after fixing
this stupid little undefined variable mistake we might as well
call it a stable version.
Once we have a stable version that has been tested and is ready for a production environment,
it's a good idea to create a tag for it in SVN.
A tag - as well as a branch - is basically just a copy of the code base as it appeared
at a given time. This tag can be then used to deploy a stable
version of the product to the live environment or even roll back the next deployment in case
something goes wrong.
We use tags here instead of branches, as branches are mostly used for work on different aspects
of a product that are later merged into the trunk,
while tags are looked upon more as a constant snapshot of the project that do not change
over time and can be used as a checkpoint.
Now that we have the code tagged, we're free to continue our work in the trunk as desired,
since no more changes would normally make it into the tag.
There are always exceptions, for instance when - let's say due to a poor testing environment
- errors are discovered in the staging server from which
the code is being copied to live site. In such cases, there could be changes even to
tags, however these are tested changed and do not usually put
the product at risk.
Let's now create a new branch to work on the JavaScript validation aspect of our Age Calculator.
This will result in a cleaner workflow for our colleagues,
since they will not need to browse through history of the trunk should they find an error
and need to revert some JavaScript changes back to a previous state
later. Also, it will not in any way interfere with the stable development of trunk, as the
trunk should only ever contain code that is tested and ready for
a peer review process. In other words, trunk should always be kept as stable as possible.
We will put our JavaScript validation back to the JavaScript branch, re-test it and make
it ready to be merged back into the trunk. Once that's done, we can switch back to trunk
and start the merge process.
A merge is basically a way to pull changes from the branch back to our trunk in the most
automated way possible. Please note that the merge dialog has 2
or 3 different possibilities to merge a branch, depending on the SVN adapter version you're
using. In short, the URL variant will pull changes from a branch
back to trunk, the 2 URLs tab allows you to merge 2 different branches back into the trunk
at once and the last tab - reintegrate - seems to be the same as
the first tab, however also seems to be deemed a legacy way to perform merge. All 3 options
will result in basically the same code base anyway, so we'll only
talk about the first one here.
During the merge, SVN will automatically compare changes between current trunk and the selected
branch and will update the trunk with all non-conflicting
changes it can find. Should there be any changes that are in conflict with the state of our
current trunk, they will be marked as such in the same way we saw
in the previous episode.
All changes made to your local workspace after the merge will remain local, so you can test
the product for stability issues before you commit those changes
back to trunk.
This is in short the way I use trunk, branches and tags in SVN when I work on a project.
Now, there are two more interesting features in Subversive that I would like to show you
before this episode comes to an end. Of course there is probably a whole universe
of SVN commands and possibilities that exist on top of this and are not covered by the
Subversive graphics environment. However this is largely out of
scope of these series and also require some geeky command line mind which does not need
series like this at all.
The first nice feature is the possibility to exclude certain files from being included
in the SVN repository by the means of ignoring them.
Let's say we have a local ToDo list which is unlikely to be useful to anyone else besides
us, so we want to keep it local. To prevent committing this file, we can use
the ignore feature of Subversive which will bring up a simple dialog. Here we can choose
whether to ignore this single file, all files with a certain extension
or a regular expressions-enabled pattern of files. Once we choose one of the options,
the file will no longer be checked by the SVN when doing commits or
updates.
Please note that since this is an SVN command, by adding the file to the ignore list, you
are also committing this change to the SVN. This will basically mean
that anyone who will create a file called todo.txt in their local trunk will not be
able to commit this file to SVN until this file is removed from the ignore
list.
Also note that if we choose only a single file, SVN will ignore only the exact file
on the exact path. If we were to create an extra todo.txt file in another
folder, it would not be ignored and can be committed to the repository.
Last but not least is the ability of Subclise to export your project. While it may seem
useless to do so, looking at your project with hidden files displayed
will tell you that SVN actually creates .svn folder under each of your project directories.
This is for SVN's internal purposes and thus is hidden from the eyes
or the usual coder - even in Eclipse. However, if you were to upload all folders to an FTP
using a client that copies over everything, all these .svn folders
would be unnecessarily copied over as well.
By using the export option you get clean copy of your project without any hidden folders.
However, this route does not provide you with any options, and so I found it much more useful
to use Eclipse's own Export command to do this. By going to File,
Export or right-clicking the project and choosing Export, you can save your full project without
SVN subfolders as well as choose which files and directories
you want to export. This is especially useful if your project has some design folders which
should not be present on the live site.
This concludes our ninth episode about SVN branches and tags and also finishes our SVN
introductory as such. Next episode will pretty much depend on the
demand for what's new in Eclipse Kelper versus the basic usage of Git repositories.
Who wins - you decide.
Until next time then, thank you all for watching and... adios!