Visual Sourcesafe vs SVN, AnkhSVN, TortoiseSVN

Comments

# cruizer said on May 25, 2006 10:38 PM:

i don't think subversion allows exclusive locks or checkouts of files

# jokiz said on May 25, 2006 10:56 PM:

i think they do for future 1.2+ versions

# velocity said on May 27, 2006 8:07 AM:

You actually have that with subversion. Look for the 'lock' option whenever you check out code.

However, what you should really look at is why you need to be editing the same piece of code at the same time. ;-)

http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.locking

# velocity said on May 27, 2006 8:14 AM:

Subversion allows exclusive locks using 'locks' :-D

http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.locking

The real question is, why you need to edit the same piece of code at the same time?

# dehran ph said on May 28, 2006 8:32 PM:

I think most companies that uses SVN has "No merge" policies. In our company we're dont merge, always exclusive locks.

# jokiz said on May 29, 2006 8:27 PM:

velocity:  locks just like the docs say is ideal for binary files.  although it can be used for code files, you will only find out that a file was exclusively locked by another user when you commit, time wasted since you have already applied your changes.

>The real question is, why you need to edit the same piece of code at the same time?

why not?  for a team, there will be a time that both members will be editing the same code sheet.  one good example is a helper class for a web project.

# jokiz said on May 29, 2006 8:28 PM:

dehranph:

>I think most companies that uses SVN has "No merge" policies. In our company we're dont merge, always exclusive locks.

where did you get that statistics?

# velocity said on May 29, 2006 11:39 PM:

first of all, "merge" can't be all that evil ;-) If you find yourselves editing the same places in the code most of the time, then it may be a "super" function. Maybe its time to refactor. Or maybe you just can't agree on the best implementation so the last editor wins ;-)

I don't generally agree with the lock-unlock method of visual source safe. It's counterproductive. Imagine editing the web helper class. In a lock-unlock model, if I wanted to edit the class, I have to wait for my turn. When my turn comes, I'd have to rip out the code I don't like and replace it with mine. The "waiting" part is counterproductive. OTOH, in the "edit-merge" model, if merging conflicts take time, I believe its still less time than wait-and-rip. Besides, it's easy to just choose one version over another rather if the conflicts are logical.

# jokiz said on May 29, 2006 11:52 PM:

"super" function - can be, but there really is a possibility that two members will be editing the same code sheet, either revising or adding functionalities.

i am very suprised that this "waiting" is very common to vss users. sourcesafe have this "allow multiple checkout" option which is off by default.

# byron walker said on August 3, 2006 9:06 PM:

ive beenusing SVN for about 9 months now, with a project team no bigger than 2.

Interesting you say that communication is important when using svn. Isnt communication paramount in software development?

Thats why we have standups, pairing, and the war room.

# jokiz said on August 3, 2006 9:44 PM:

hi byron,

i agree with you but the simple warning for vss that another user is currently using a file i believe is very helpful for some scenarios.

# paul barrett said on September 7, 2006 11:50 AM:

Actually, my problem with it has not been the same file edits but project files that are checked in. If I add a form, dataset, class, etc.. then we have problems with the project file. What would be a better way to handle the new files and changes to the project file.

# jokiz said on September 7, 2006 8:07 PM:

hi paul,

the only problem i see is when two developers have modified the same project file.  usually a manual conflict resolve will do the trick and if it's tedious for you, the second guy can just update his version of the project file before doing his changes (like adding or removing files)

# Frank said on December 7, 2006 5:01 AM:

Christ, the issue here is not wether or not there is a flaw in the design forcing developers to edit the same file, or even some of the same lines of code; you are just moving away from the real issue.

I have experience with both vss and svn. vss in teams up to 45 people and svn in teams up to 9 people. I have never experienced the supposedly long waiting hours in vss, but i HAVE experienced numerous problems with svn. Both major merge problems, but the merge algorithm/approach is also flawed. Several times i have experienced that svn merges with no conflict - only to find that some of my bugfixes/features are _gone_. This leaves all of us with a sence that things will blow up each time we do a commit, and some times they do.

And on the more irrelevant side: the tortoisesvn gui is counter intuitive.

Bottom line is: i will never recommend svn, except when purchase price is a major issue. And even that won't hold, since buying software is far cheaper than having a team of developers being only 80% productive due to missing code, faulty merges etc.

Granted, vss has some issues (i believe that is the Microsoft translation of "bug"), but basically the checkout/edit/checkin approach is _way_ less errorprone.

# jokiz said on January 30, 2007 11:54 PM:

hi frank,

months have passed and we haven't had any conflicts with subversion such as yours, specifically the bug in merge (if there is any).  locks are real pain and i agree now as confirmed with some of my friends.  i guess the key to us is we're using CI, so i commit on an hourly basis to prevent these conflicts.

i think i can relate on the merge conflict and i believe it happens even in vss.

# juan said on April 26, 2007 9:07 AM:

I agree with Frank, svn sucks! We were forced by the team manager to use it and we all (a 10+ people team) miss the good old vss times. The edit merge model is not for us. My main complain is you don't get any warning when modifiying files that other persons are modifying at the same time. At least you should have given the option to wait. Then you go througt the tedious colnflic solving process. awful

# Wes Weeks said on July 17, 2007 7:32 AM:

I realize this is an old thread, but I have to post(rant) somewhere.

Running naked full speed into a giant saguaro cactus is painful...

Getting 1000 papercuts on your face is painful...

100 monkeys armed with hammers trying to hit you in the crotch is painful...

SVN is something much, much worse.

I am at a client site where they recently made the switch from VSS to SVN due to a source safe database crash (so I'm not promoting VSS here).  But the switch to SVN (using both TortoiseSVN and ANKHSvn) has been the proverbial jump from the frying pan into the fire.  I have spent more time in the last month fighting conflicts, merges, lost files etc then I have in my prior ten years as a developer.  Developers cringe when they have to commit their changes (so they dont' do it as often, not a good thing) at what they will probably face trying to resolve conflicts.  The standard now before committing changes is to make a local backup of all of your source code beforehand due to issues with files coming up missing.  I didn't think it was possible to both Suck and Blow at the same time, but I have since been proven wrong.

I am on a team with only three developers.  I shudder to think of what trying to develop on a larger them with this POS must be like.

Save yourself a lot of time and grief.  If you are switching from VSS, looking at Team Foundation Server or SourceForge Vault (I'm sure there are others as well, but these are the only ones I'm familiar with).  I wouldn't voluntarily use Subversion again if I was paid $100 every time I modified a file. (well I might at that price, but I'd have to think about it ;)

If I can just save one person from going through my pain, I can rest easy when I die knowing I have eased the suffering of another...

# rmisra said on September 2, 2007 1:59 PM:

Automated merges never made sense to me to begin with but with SVN there have been conflicts 90% of the time where SVN has attempted to merge local changes during a checkout.

The whole idea of an auto-merge is counter intuitive. Suppose developers A and B are working on file 1. Both A and B go through their unit testing and A checks the file in and B merges those changes back into their working copy. Doesn't this mean that B should really re-unit test since they really do have a new code file?

Also we have a development team of 20 and we have mandated a lock-modify-unlock process in our production pipeline and we have NEVER had anyone sitting there twiddling their thumbs with nothing to do because someone else has a file they need. We simply have them work on something else until the file they need is is available.

# basildonbond said on September 11, 2007 7:27 AM:

I read Wes's excperience with incredulity...

Anyone losing code when committing to svn really needs to rtfm - see svnbook.red-bean.com/.../svn.tour.cycle.html

Doesn't anyone spot all those files with .mine extensions appearing in their working folders?!!!

See also svnbook.red-bean.com/.../svn.basic.vsn-models.html

for a good discussion of lock-modify-unlock vs. copy-modify-merge.

# Guy N. Hurst said on September 26, 2007 2:07 PM:

With the merge model, you should always do an "svn status -u" to see if someone else already made changes before you commit. If there are changes already there, you can do an "svn diff" with various options to see what they are. If you don't go through a process like this before you commit, you will indeed have headaches!

Another thing, there are known issues with AnkhSVN not doing a rename properly. I wouldn't judge SVN based on a freeware graphical interface to it. At its core, it is a command-line program, and that is how I have used it for 18 months. I think it is great! It is reliable, secure, and fast. But again, people using this tool need to use it correctly by following an orderly process.

Currently, we are considering using it not only in our Unix environment, but also on our Windows/.NET platform in place of VSS. I am checking out various integration options for use with VS2005. I personally would avoid AnkhSVN until it improves. Right now, it seems to be giving SVN a bad name...

Guy

# Mark said on November 16, 2007 2:38 AM:

Just to add my two cents. I just have switched one 3man team from VSS to SVN. SVN just rules and have I see no reason to go back to VSS. I will switch the whole company to SVN asap.

The merge "problem" is not really a problem. working  on the same file is fine and merging easy if the two developers are working on different functionalities. If they have to work on the very same function .. well that is in general bad comunication/planning.

SVN atomic commit is a priceless feature VSS does not have. With each revision we commit discrete functionalities, and a single revsion number is all u need to refer to a specific code base line up. Someone said Tourtoise is counter intuitive .. well it get some getting used to to do SCC ops from the shell rather than from the IDE but I think it is much better than VSS explorer.

Furthermore we have integrated SVN with Bugzilla    have a bunch of post commit hooks that handle notifications and log msg policy enforcement.  can u do that with VSS ?

Bottom line if u want to swithc to SVN and hope to use the same workflow as with VSS just don't but if u go through the effort and embrace the modify-merge philosophy it just rules.

# tortoise svn merge sucks said on May 15, 2008 10:04 AM:

Pingback from  tortoise svn merge sucks