[655 total ]
Changed handling of output of pre-lock hook in SVN 1.6

One of our customers reported a funny issue with the pre-lock.bat hook
script. Yes, when he used Subversion Server on Windows system. The
customer is using a custom pre-lock.bat script to explicitly lock the
file before every ... [More] commit.

Why does he explicitly lock the file while svn commit itself locks the
file implicitly? He has a valid reason to do so.

In earlier releases (v1.6), Subversion discarded the stdout messages
printed in hook scripts. It is applicable for all hook scripts including
pre-lock.bat script. Starting with v1.6, it behaves the same with all
hook scripts, except the pre-lock.bat script. The message printed in this
hook script is used as a UID for the lock. It should be unique across the
repository. The best part about Subversion is that it is clearly
documented in the Subversion 1.6 Release Notes.

Guess what? The customer complained that the custom pre-lock.bat script
worked very well in prior releases, but it do not work with Subversion
1.6. When he performed a file commit, he faced a 423 Locked Error error.
We attempted to release the lock obtained by a different user, if any,
using svnadmin rmlocks and svn unlock --force commands, but they did not
help. When we investigated if it has to do with any stdout messages, we
discovered that NO it didn't. The hook script does not print any message
to stdout.

WHERE THE PROBLEM EXISTS?

The issue is that the customer has set echo on globally in his Windows
system. It prints all the commands we execute in the hook script to
stdout, including the comments as in rem command.

The solution is to set echo off in his system, and he no longer faces the
problem! [Less]

Changed handling of output of pre-lock hook in SVN 1.6
Subversion 1.6 Security Improvements

When you use softwares which requires a username and password to be keyed
in every time you access some resource, it becomes a pain. On the other
hand if that software is capable of remembering your username and
password, then it is a ... [More] great advantage. But what if the username and
password which is remembered by this software is stored in plaintext at
some location in your system? Isn't it a security risk? Of course yes,
specially when you don't know that your passwords are stored in
plaintext. This was the case with subversion till 1.6.0, but now we have
greater security improvements to subversion 1.6 which aids us with a lot
of features to avoid such a scenario.

Warn caching of plaintext passwords

From the past subversion had capabilities of caching passwords, but in
systems which does not have a good method of storing these passwords in
encrypted form, subversion silently cached passwords in plaintext, which
was bad, since the user is not aware of this fact, specially the new
users of subversion. On one fine day when they come to know about this
fact, they are disappointed. So we thought of solving this in the
subversion community since this was a common problem reported by many
users in the mailing list. Subversion 1.6 behaves in a different way when
it is about to cache passwords in plaintext, as you can see from the
following sample run,

 
$ svn co http://localhost/svn/repos wc
Authentication realm: TEST SVN repository
Password for 'stylesen':
-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:

TEST SVN repository

can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/home/stylesen/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? yes
Checked out revision 0.
$

Thus the user is aware that his password is cached in plaintext. What if
the user decides not to store the passwords in plaintext, but don't want
to get prompted each time? In such a case the user can play around with
the following options in subversion servers file, ie.,
'~/.subversion/servers'

Globally,

[global]
store-passwords = yes
store-plaintext-passwords = yes

Per server basis,

[groups]
group1 = *.collab.net
othergroup = *.example.com

[group1]
store-passwords = yes
store-plaintext-passwords = yes
[othergroup]
store-passwords = no
store-plaintext-passwords = yes

Oh wait, all the above is specific to *NIX users, we already have
mechanisms built in Subversion to cache passwords in encrypted form using
wincrypt API in windows machines and Keychain services in Mac OS.

Okie, that is cool, but yet *NIX users like me are not happy, since we
don't have a proper mechanism in place which stores passwords in an
encrypted form. That is not true anymore, since 1.6 comes with support to
cache passwords/passphrases in an encrypted form in GNOME Keyring or
Kwallet depending upon the desktops they use. The password store could
also be chosen with the following parameter in the subversion config file
ie., '~/.subversion/config' as follows,

[auth]
### Set password stores used by Subversion. They should be
### delimited by spaces or commas. The order of values determines
### the order in which password stores are used.
### Valid password stores:
### gnome-keyring (Unix-like systems)
### kwallet (Unix-like systems)
### keychain (Mac OS X)
### windows-cryptoapi (Windows)
password-stores = gnome-keyring , kwallet

GNOME Keyring

In order to enable Subversion to cache passwords in GNOME Keyring we need
to pass the following parameter to the “configure” script while compiling
Subversion source.

--with-gnome-keyring

The above requires GNOME Keyring libraries available in the operating
system, failing which Subversion falls back to caching passwords
unencrypted. Once you have Subversion binary compiled with GNOME Keyring
support, the password is automatically cached in the Keyring, provided it
is unlocked. CollabNet subversion binaries are compiled with GNOME
Keyring support which you can use right away, to get this feature.

Gnome-keyring-1

Gnome-keyring-2

What if my GNOME Keyring is locked? Subversion provides a way to solve
that too,

$ svn co http://localhost/svn/repos wc
Password for 'default' GNOME keyring:
Authentication realm: TEST SVN repository
Password for 'stylesen':
Checked out revision 0.
$ svn co http://localhost/svn/repos wc
Checked out revision 0.
$

KWallet

KDE users are not left alone, you can make use of KWallet in order to
store passwords in encrypted form. In order to use KWallet the Subversion
binaries must be compiled with the following option

--with-kwallet

SSL client certificate passphrase caching

As we know, subversion was good at caching passwords, but it didn't had
any mechanism to cache SSL client certificate passphrases, may be this
was never thought, since the users were limited. The only way to avoid
entering client certificate passphrases each time was to hard code it in
the servers file with the parameter ssl-client-cert-pp, which is ugly!
But now in 1.6 we use the same infrastructure as above to cache SSL
client certificate passphrases.

store-ssl-client-cert-pp = (yes/no )
store-ssl-client-cert-pp-plaintext = (yes/no)

Aren't you curious to watch this in action? Here we go,

$ svn co https://localhost/svn/repos wc
Authentication realm: https://localhost:443
Client certificate filename: /home/stylesen/stylesen.p12
Passphrase for '/home/stylesen/stylesen.p12':
-----------------------------------------------------------------------
ATTENTION! Your passphrase for client certificate:

/home/stylesen/stylesen.p12

can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passphrase encrypted, if
possible. See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-ssl-client-cert-pp-plaintext' option to either 'yes' or
'no' in '/home/stylesen/.subversion/servers'.
-----------------------------------------------------------------------
Store passphrase unencrypted (yes/no)? yes
Checked out revision 0.

Thus Subversion 1.6.x brings in lot of security improvements which
enhances and gives a better user experience. [Less]

Subversion 1.6 Security Improvements
.NET Remote Client Library Released for CodeBeamer

CodeBeamer 5.3, the latest series of the award winning Collaborative ALM
Solution, ships with a new .NET remote client library.

This library is the complete language

The Subversion Learning Curve
The Subversion Learning Curve

At CollabNet we have been discussing the differences and similarities
between the Open Source community, and the Enterprise community. We want
to be sensitive to that fine line between information awareness and
marketing, without falling ... [More] to one side or the other. Some people at
CollabNet are hesitant to point to anything that costs money to the Open
Source community for fear of offending, yet much of the content could
indeed be very useful in shortening that learning curve.

As someone who is also helping to maintain the CollabNet site, and as
Community Manager, I needed to learn what I needed to know as quickly as
possible. I am not only learning to use Subversion, but I’m also learning
to use the collaborative tools provided by TeamForge.You can see the
tools of CEE if you look at any project on openCollabNet. We will be
upgrading the site to TeamForge in the future.

Yes, we eat our own dog food, so to speak, and I’m glad. I have been
impressed with the functionality and the ease of use of this platform
compared to others I have used. To shorten my learning curve I have found
some great training through articles, white papers, webinars, and web
courses.

It is my hope that the resources I list below help to shorten your
learning curve, no matter whether you want to stick with only the free
materials or the ones that we charge for.

For those of you who are Subversion experts, you can stop reading here,
though I value your opinion and experience and would appreciate any
comments or suggestions you’d like to make. Also, some of you may not be
aware of the variety collaboration tools that TeamForge provides.

Newsletters

Many bypass this option when registering for CollabNet, but the
newsletter can point to useful information about learning Subversion, as
well as other content you might not want to miss. You can subscribe by
clicking on your user name at the top of the CollabNet site. Once in your
profile, scroll down and click the Newsletter box. Or you can read the
archived newsletters.

Webinars

Webinars are a great way of seeing software in action, and hearing
information about the tools. Be sure to be logged into the site so you
don't need to fill in any forms.

* What's New in Subversion 1.6

* Subversion Best Practices

* CollabNet TeamForge The Power of Centralization

Discussion Forums

Discussion forums are an excellent place to ask questions that fellow
developers and users can answer. Be sure to return the favor by answering
the questions when you can provide solutions based on your own
experience. You'll need to be logged in to participate.

* Subversion for Admins

* Subversion End Users & Developers

Release Notes, Data Sheets, and Articles

We also have some good notes, data sheets, and articles. Be sure you are
logged in so you needn't fill out contact information.

* Subversion 1.6

* Browsing a Subversion or CVS Repository

* CollabNet Subversion Datasheet

* CollabNet Training for Subversion

Training Courses

CollabNet offers a complete, role-based training curriculum across the
entire CollabNet product line. Courses are delivered in a number of
formats to best meet your education needs.

Subversion 1.5 - Individual Modules:

* Subversion 1.5 for Developers - Section 01 - Introduction to
Version Control (10 min) - $28

* Subversion 1.5 for Developers - Section 02 - Introducing Subversion
(19 min) - $28

* Subversion 1.5 for Developers - Section 03 - Global Revisioning and
Working Copies (21 min) - $38

* Subversion 1.5 for Developers - Section 04 - Standard Work Cycle
(33 min) - $38

* See More . . .

Instructor Led Courses

* Subversion 1.6 for Developers - Standard

* Subversion 1.6 for Developers - Enterprise

* Subversion 1.6 for the 1.x Developer

* Subversion 1.6 for Administrators

* See More . . .

FAQs

FAQs are probably one of the best free resources you can read for
learning about Subversion.

* Subversion Client FAQ

* Subversion Server FAQ

* Subversion Migration FAQ

As I discover more resources for learning Subversion and TeamForge, I
will write new blogs, and add to the newsletter as I discover.

Enjoy your Subversion learning path! [Less]

Subversion + Eclipse3.5 = Easy!
Subversion + Eclipse3.5 = Easy!

I added a post on my personal blog yesterday about support for Subversion
being available for the just released Eclipse 3.5/Galileo release. Today
I am going to show just how easy it is to install support for Subversion
in Eclipse ... [More] 3.5.

While I think that installing plugins in Eclipse is generally a pretty
easy process, my views on this are colored by the fact that I have been
doing it since before Eclipse 1.0 came out. That said, the Eclipse Mylyn
team has made the process super-easy in the Eclipse 3.5 release.

I started by downloading one of the Eclipse packages from the download
site. I chose the Eclipse IDE for Java Developers, just make sure you get
one of the options that includes Mylyn.

After unzipping the bundle and starting Eclipse, look for the Mylyn Task
List view and click on the New Task button as shown here:

Select New Task

This brings up the following Mylyn wizard. Note the new option to install
more connectors:

Select New Task

After clicking the "Install More Connectors" button you are presented
with a list of connectors that Mylyn can install. In the list of
connectors that has been certified by Tasktop, you will see the CollabNet
Desktop for SVN. The CollabNet Mylyn connectors, including Subclipse and
our graphical merge client, have been certified by the team at Tasktop.
That means that these plugins play well with others and can be properly
integrated into a number of Eclipse-based IDE's. Subclipse is the only
Subversion plugin to have been certified by Tasktop.

Select New Task

I checked the box for the CollabNet Desktop for SVN and click Finish.

Three clicks, and I have started the process for installing Subversion
support into Eclipse, it does not get much easier than that!

At this point, the rest is handled by the install magic from the Mylyn
team. They run through the Eclipse install mechanism to verify and
install your selections. I was doing this just after the launch of
Eclipse 3.5 and I am sure the mirrors were getting hammered. Whatever the
process does initially to validate the dependencies to verify the install
took a few minutes, but eventually the following dialogs came up and it
is just a matter of clicking through the wizard to complete the install.
For completeness, here are those dialogs:

Confirm Selection

Confirm your selections and click Next:

Verify Components

I expanded the selection, so that you can see all of the components that
will be installed. You get the CollabNet Desktop, which allows you to
connect to any CollabNet hosted site. Subclipse, and its required
components. The Subversion revision graph feature that I have blogged
about previously, and the CollabNet Merge client, which makes merging
easy and powerful from the Eclipse environment.

Accept License

Accept the licenses. All of these products are free and open-source,
licensed under the EPL.

Restart Eclipse

And finally, just click Yes to restart Eclipse. That is it, not only do
you have a working Subversion client in Eclipse, you have one with all of
the bells and whistles as well as one that has been certified by Tasktop.

One Caveat!

The above install was done on Windows Vista 32-bit. If you are running on
another operating system, you must have the Subversion 1.6.x native
libraries, including the JavaHL library available. CollabNet provides an
installer for OSX that includes this library, as well as a Linux client
RPM that should work on any Linux distro. Windows 64-bit users can
install the SlikSVN package. All of this information and more is
available in this FAQ about JavaHL. [Less]

Subversion + Eclipse3.5 = Easy!

I added a post on my personal blog yesterday about support for Subversion
being available for the just released Eclipse 3.5/Galileo release. Today
I am going to show just how easy it is to install support for Subversion
in Eclipse ... [More] 3.5.

While I think that installing plugins in Eclipse is generally a pretty
easy process, my views on this are colored by the fact that I have been
doing it since before Eclipse 1.0 came out. That said, the Eclipse Mylyn
team has made the process super-easy in the Eclipse 3.5 release.

I started by downloading one of the Eclipse packages from the download
site. I chose the Eclipse IDE for Java Developers, just make sure you get
one of the options that includes Mylyn.

After unzipping the bundle and starting Eclipse, look for the Mylyn Task
List view and click on the New Task button as shown here:

Select New Task

This brings up the following Mylyn wizard. Note the new option to install
more connectors:

Select New Task

After clicking the "Install More Connectors" button you are presented
with a list of connectors that Mylyn can install. In the list of
connectors that has been certified by Tasktop, you will see the CollabNet
Desktop for SVN. The CollabNet Mylyn connectors, including Subclipse and
our graphical merge client, have been certified by the team at Tasktop.
That means that these plugins play well with others and can be properly
integrated into a number of Eclipse-based IDE's. Subclipse is the only
Subversion plugin to have been certified by Tasktop.

Select New Task

I checked the box for the CollabNet Desktop for SVN and click Finish.

Three clicks, and I have started the process for installing Subversion
support into Eclipse, it does not get much easier than that!

At this point, the rest is handled by the install magic from the Mylyn
team. They run through the Eclipse install mechanism to verify and
install your selections. I was doing this just after the launch of
Eclipse 3.5 and I am sure the mirrors were getting hammered. Whatever the
process does initially to validate the dependencies to verify the install
took a few minutes, but eventually the following dialogs came up and it
is just a matter of clicking through the wizard to complete the install.
For completeness, here are those dialogs:

Confirm Selection

Confirm your selections and click Next:

Verify Components

I expanded the selection, so that you can see all of the components that
will be installed. You get the CollabNet Desktop, which allows you to
connect to any CollabNet hosted site. Subclipse, and its required
components. The Subversion revision graph feature that I have blogged
about previously, and the CollabNet Merge client, which makes merging
easy and powerful from the Eclipse environment.

Accept License

Accept the licenses. All of these products are free and open-source,
licensed under the EPL.

Restart Eclipse

And finally, just click Yes to restart Eclipse. That is it, not only do
you have a working Subversion client in Eclipse, you have one with all of
the bells and whistles as well as one that has been certified by Tasktop.

One Caveat!

The above install was done on Windows Vista 32-bit. If you are running on
another operating system, you must have the Subversion 1.6.x native
libraries, including the JavaHL library available. CollabNet provides an
installer for OSX that includes this library, as well as a Linux client
RPM that should work on any Linux distro. Windows 64-bit users can
install the SlikSVN package. All of this information and more is
available in this FAQ about JavaHL. [Less]