VSS to Subversion

Question

I'm researching a potential move from SourceSafe to Subversion and we are struggling with the edit/merge/commit vs. checkout/update/checkin paradigm. The primary concern is how do you know which files are checked out with Subversion (and to whom)?

Is there a Subversion equivalent to "Status Search" in VSS? Or is it not possible because of the lack of "reserved checkout"?

Also, if we do try and implement "reserved checkouts" with Subversion via "locks", is there a GUI (TortoiseSVN, VirtualSVN, etc.) that supports "lock on checkout"?

Thanks.

Update: Example, before we do a build/release we want to be absolutely sure that all files are checked-in. Developers forget. So we DO need to know which files are checked-out. Is this possible with Subversion? Is is possible to view a list of checked-out (or locked) files? Browsing the entire code-base in Explorer is not feasible, is there some report-style list or search functionality?

Answer 1

I'd really recommend moving to Subversion (or, frankly, even pen and paper) over VSS. To more precisely address your question; using Subversion, you shouldn't need to know who's got a file checked out as severely as you would with VSS; Subversion (and reasonable source control systems) don't have the hissy fit with merging changes that VSS does.

Answer 2

TortoiseSVN will tell you if files are locked, a lock icon will appear over the files when you view them in explorer or the repo browser.

However, the standard operating method of SVN is not lock/update/unlock like in VSS. "Checkout" in SVN is similar to "get latest version" of VSS.

Personally, I would avoid the lock/update/unlock workflow. The merging algorithms in SVN are much better than vss. Lock/update/unlock is fundamentally opposed to concurrent development.

Answer 3

If you are using the edit/merge/commit paradigm (which you don't have to w/ Subversion, btw), then there is really no such thing as a person "checking out" a file.

With edit/merge no files are locked, and you are to assume that every file is checked out (unlocked) to every user.

Developers pull down the whole baseline (or at least the portion they want to build), and they just edit whatever they want when the mood strikes them. When they want to check their changes back in, that's where "merge" comes in.

At first blush you, as a VSS user, might think a check-in of a file could "wipe out" changes made to that file since you checked it out. I didn't understand how that could work initially either. The trick here is that SVN can tell when someone else checked in a version of that file since you checked it out, and thus it needs to be merged rather than simply replaced. It is smarter than VSS. :-)

The theory is that it shouldn't happen much, and in the long run you will spend less time dealing with conflicting edits than you would spend trying to deal with files someone else has locked. A quick back-of-the napkin calculation I did once showed that is probably correct where I work, but YMMV.

---

Update: For your procedure where you try to protect developers from forgetting to check in changes, that probably isn't going to work anymore. You could try to root around in every developer's working directories and look for differences, but I think we both agree that isn't feasible.

It is correct that the locking model provides a way for developers to declare their intention to modify a file to the central repository, and edit/merge does not. Tools built for one approach often just flat out make no sense for the other. This is one of those cases.

My suggestion to you as toolmeister would be to try out a small (or toy) project with SVN to acquaint yourself with the different method of working. Once you understand that, you ought to be able to wrap your head around it.

Answer 4

SVN is optimistic: merge conflicts are rare and easy to resolve. VSS is pessimistic: merge conflicts are so hard to resolve that you avoid them with locking. So in svn, you don't need to know that a file is "checked out". You just check out a version without locking and edit as you like. Conflicts are resolved before commit, and usually svn resolves them automatically for you, unless two or more commits are modifying the same source lines.

Therefore a "status search" is not really needed.

SVN does support the notion of locking, which is useful for those hard-to-merge binary files. Even there the lock is not hard; it's merely a signal to other developers "please do not commit while I'm editing this file." SVN GUIs have the option of locking a file. You can also enforce locking with the special svn:needs-lock property.

See the svnbook for more info on locking: http://svnbook.red-bean.com/en/1.2/svn.advanced.locking.html

Answer 5

AnkhSVN supports lock on edit from Visual Studio, but even though I worked on that feature I would really recommend using this only when there is no other option (e.g. specific generated code and binary files). For normal source files in a team where developers are working on different tasks it is almost never necessary to perform exclusive locking.

Good 3-way merge tools like the free SourceGear DiffMerge make it very easy to resolve an occasional conflict once you have one (probably once every few months over the entire team; not more).

Answer 6

Matt,

As a former VSS user who has moved to SVN, I can understand your frustration. However, I believe that you have already answered your own question. You've indicated that you are struggling with the shift from the "lock/edit/unlock" mindset to the "update/edit/commit" mindset and this is really the source of your frustration. I know, because I have been there myself.

Fundamentally I think that the problem you are trying to solve is based on the "lock/edit/unlock" mindset... which (as has previously stated by other answers here) is the "restrictive security model", ie we want to protect you from doing something harmful so we will restrict your level of access. The "update/edit/commit" mindset basically takes the approach that 90% of the time the user (in this case the developer) is trustworthy and knows what they are doing and so we will allow you to do what you want and provide you the tools to deal with the small number of times when you get yourself into trouble.

If I may be so bold as to restate the problem you are attempting to solve is:

"Sometimes developers are in a rush to deploy a new change. They might forget to commit a change back to the repository that is critical for the new change to work. This will mean that the Build / Release process will fail due to this missing change. The Build / Release process needs to know if there are any files the Developer intended to change, but whose changes have not yet been saved back to the repository."

The resolution to this problem would then be for the developer to commit the change they've overlooked and re-initiate the build process for a successful outcome.

Can I ask, how many times has this actually happened for you? After doing it once, how many times would a developer do it a second (or subsequent time)? If they were a continual offender, how many times would you as a Team Leader / Manager allow it to happen before that Developer was "encouraged to seek external career opportunities"?

So, basically, my answer is... train your developers to not forget and deal with the occasional instance where they forget.

I assume that by asking the question if it is possible "to view a list of checked-out (or locked) files?" that you are intending to enforce exclusive locking of all files in the repository (otherwise there is no concept of a 'locked' file in SVN)? This then severely limits one of the big advantages of SVN (or any other "update/change/commit" model SCM) over VSS (or any other "lock/edit/unlock" model SCM).

Cheers Richard

Answer 7

I appreciate all the answers/opinions. However, just to close the loop, if you do choose to go with the lock/edit/unlock paradigm, which is possible with Subversion, you can use TortoiseSvn to view all current locks for all users.

• Select TortoiseSvn | Check for Modifications, then select "Check Repository".
• A list of files is displayed.
• There is a "Lock" column that shows the user who has the file locked.