When I started development, CVS was on its end. I used it for a real short period of time, but I was glad to learn SVN instead. I don’t even recall how to do anything or how it works…
I used SVN, on the other hand, for some years. While the Apache tool is relatively good, and my use considerably improved when I leaved Windows and made the switch to Linux, the transition shock was even greater when I switch to Git.
Upon learning the stage mechanism, I knew I would never go back. Time passed, and I slowly learned Git tricks, developed my workflow, became the local guru. Teached Git to numerous of my friends and co-workers.
And recently, in my new job, I had to start projects once again with SVN.
After some tinkering, it comes out that while SVN isn’t as popular, nimble, or cool than git, while its features aren’t as practical to use, there is a number of workaround that make the developer life easier nonetheless. Here are some of the tips I learned.
Changelists are a kind of staging mechanisme for SVN. You add files to lists while working, then can commit each list independently. It also has the advantage of not needing you to list every file on the command line, which is a relief.
svn changelist <listname> <file>*
svn status command will then display file grouped by changelist when they are.
Note that the files need to be tracked to be added to a changelist.
When committing, the changelists are lost, unless you give the command the corresponding option.
svn commit -m "Commit message" --changelist <listname> --keep-changelists
This trick is simply a clever use of the
-F option of the
svn propset command to read the ignored files from a file rather than command parameters.
Simply write the list of ignored files on a
.svnignore file, commit this file, and after each change, just to a
svn propset svn:ignore -R -F .svnignore .
Et voilà !