We are using Tortoise svn as we have some issue we are going to move to VSS. Is Visual source safe comes along with VS2010 or should we buy separately and install. When we called and asked they said to select VSS from Tools->options->Sourcecontrol. If I do so I am getting some error as
As someone already answered on a comment, VSS does not come with VS2010.
In any case, I would strongly recommend against using VSS as your source control. It is several generations old technology as source control systems go.
It has serious drawbacks for the whole development process compared to the modern competition and should be generally avoided.
I have no idea what problems you have with SVN, but I would bet they are more of the organizational sort than technical.
From your comment I can infer that you expected SVN to give you same type of pessimistic locking workflow you had coming from VSS, but with SVN and other more modern tools, you have to change your expectations and workflow to a more natural parallel development.
In SVN you do not need to keep track of who changes what, as everyone can check out and modify every source file in the source tree and in most cases unless the developers change same lines in a same file simultaneously, the changes get merged together without any manual intervention whatsoever.
Instead of acquiring exclusive locks to a source file to modify it, you synchronize your local working copy before commiting it back to the repository and resolve any conflicts locally. This way nobody needs to keep track of who is working on what, just remember to update the working copy and resolve any odd conflicts before a commit.
Visual merge tools hep here tremendously.
Once you've converted, you'll love it and never want to go back.
If SVN does not work for you, there is a commercial tool called Vault by nice guys at SourceGear specifically designed as a replacement to VSS.
In case you feel especially adventurous and liberalized from the VSS, you might also take a look at the Veracity by same guys - a distributed version management tool much like the popular Git and Mercurial.
VSS does NOT come with VS2010 but you may still use it as a form of source control...although this is highly advised against.
Related
Here's the requirement:
C# classes need to be shared among a group of 5 developers.
If one developer starts editing a class, it should be automatically locked for others
Others can edit that class, only when the current developer releases the class
I understand that Git is a distributed version control system, whereby complete local repositories are created. Merge functionality has to be used for creating a consolidated file.
I have also tried Svn, but even that uses a Merge tool.
I have a small team, and I don't want to use Merge Tools. Which is the best way to accomplish this?
SVN does support this kind of workflow with its locking feature.
Read the section on locking in the SVN Book v 1.7 - it goes into plenty of detail.
As far as Im aware git does not support a locking workflow.
Apparently Team Foundation Server also supports a locking workflow, but I'm not familiar with it.
I will add that i do not think this a good way to work unless you absolutely have to (eg binaries or hard to merge files like model xml). Regular team communication and defensive programming should mean that the vast majority of code merges will be handled automatically by your version control system.
Merging is just a part of collaborative development. Nobody really wants to use merge tools, but IMO having to do an occasional (sometimes messy) merge is a far better prospect that having to wait until someone else is finished with a file before I can make my change - changes which are very likely NOT to conflict with others changes anyway. Especially in a small team.
You should also not (as mentioned in comments above) need a resource dedicated to Merging. A merge is best done by two people.
The developer with the conflict, and
The developer who committed the last change (that has caused that conflict.)
If these two can't work it out pretty quickly, or you really do need a resource just for merging (which I have seen occur even in smallish teams of around 10 developers) you have problems.. such as;
The code is monolithic/highly coupled and needs refactoring
The developers are not committing atomic changes.
Using svn and a complex branching strategy (scary)
Developers are not talking to each other (Just a 10 min standup/day would help)
Good luck!
Apache Subversion 1.8 features major improvements that make merging and solving conflicts easier. New automatic merges are definitely worth testing!
As #mounds already mentioned, you can use pessimistic locking kind of workflow with Apache Subversion. See the SVNBook | Lock communication section. In such case Visual Studio with VisualSVN will prompt you to lock a file before you start modifying it.
Note that such approach should be used with those files that can't be merged. So~, Embrace Merge!
Users and administrators alike are encouraged to attach the
svn:needs-lock property to any file that cannot be contextually
merged. This is the primary technique for encouraging good locking
habits and preventing wasted effort.
I am programming in Visual Studio 2010, using TortiseSVN and VisualSVN as my client to connect to SVN repositories.
I am having a bit of a frequent problem though with the whole SVN thing in general. One thing that keeps cropping up is that if I make changes to files - namely filenames, or move them to new folders, etc, I end up getting all kinds of conflicts with the repository and it just causes all sorts of strange errors.
I understand the importance of version control and check-in/check-out access like this, but what do most of you do to deal with this kind of thing? I mean, I've tried doing the whole 'Remove from Subversion', change my file, then 'Add to Subversion' thing, and it just doesn't seem to do the job very well. This is especially frustrating when working on web projects where filenames can change very frequently as a project evolves and becomes multifaceted.
Are there any standard ways to deal with this kind of thing, or is it just one of the flaws of SVN in general?
First I must admit that over the last years I stepped in every pitfall SVN offers.
But in 99% it was my fault.
Common mistakes are:
Renaming a file and only changing lowercase.txt to UPPERCASE.txt (Windows only, to avoid this change the name to UPPERCASE1.txt first and than to rename to UPPERCASE.txt)
Using the explorer for Rename / Delete / Move operations (better use Tortoises Build-In methods
Cross Merge related conflicts
and some more I can't remember at the moment.
I haven't used visualsvn yet, but I think it is build on top of Tortoise. If you use Visual Studio, I would recommend ankhsvn http://ankhsvn.open.collab.net/ which has a great integration into visual studio and catches most mistakes you can make (all from within the IDE).
Another tip: don't try to move/delete/rename a whole bunch of files AND directories in one commit. There is at least a couple of bugs in subversion server and client v1.6 (where both Ankhsvn and tortoise depend on) that screw up at least your working copy. A multiple commit approach will work (so first rename, commit, then move one folder, commit, etc).
Subversion processes file name changes as a delete and an add, which can be somewhat problematic. It's just an inherent limitation of Subversion and is a part of why some of us have switched to using different version control systems.
Forgive me, but I don't know the technical term to know what to search for.
I am trying to find a way to keep track of changes in my code during the development of my program. something that would allow me to go back to a section of code that I deleted. I am not talking about "undo". But rather a way that would let me keep track or be able to retrieve a section of my code that I deleted but now want it back.
Is there such a way? If there is, then what is this whole system/procedure called? Is there something that integrates with Visual Studio 2010?
you could use
SVN
or
GIT
but for local use, I would prefer SVN. its free and its easy.
For visual studio there are a few SVN client plugins (like VisualSVN). But, I would suggest TortoiseSVN as the client.
To be clear, SVN is the server, TortoiseSVN is the client. (Both are free open source tools)
It's called Revision Control.
The term you are looking for is Source Control. Modern source control's provide all the functionality you described plus much more.
Team Foundation Server seamlessly integrates into VS2010 and is very useful. Read through Source Control for Visual Studio to get up to speed.
I'm not familiar with Visual Studio, but generally there are two approaches to implementing this:
1) Source/Revision control - But the problem is that it is very low-granularity, you usually commit a file when it is ready, but lose any interim changes. There are a lot of solutions compatible with visual studio.
2) A local history that tracks multiple versions between commits. Eclipse has this built in, not sure how to access it in VS.
3) A very granular log of all your development activities so you can examine and revert past changes. Not familiar with a commercial version of this. I once developed something like this for Eclipse.
Please read this thread here at SO: Keeping track of changes I make by copying project folders.
subversion has a lot of mind share these days, but it's very old-school, first-gen tech. Distributed revision control is gaining a lot of momentum and I'd highly recommend that you become familiar with it if you're going to be a code monkey professional. Look up mercurial (also referred to as hg) or bazaar. If nothing else, perforce - a professional, commercial revision control tool - is free for up to two users. It works very well, as long as you keep your branching craziness to a minimum.
Every source control does that, you know ;)
YOu have a legal VIsual Studio 2010? Try Team System.
I've used source controls for a few years (if you count the Source Safe years), but am by no means an expert. We currently are using an older version of Sourcegear Vault. Our team currently uses a check out and lock model. I would rather switch to a update and merge model, but need to convince the other developers.
The reason the developers (not me) set up to work as check out and lock was due to renegade files. Our company works with a consulting firm to do much of our development work. Some years ago, long before my time here, they had the source control set up for update and merge. The consultants went to check in, but encountered a merge error. They then chose to work in a disconnected mode for months. When it was finally time to test the project, bugs galore appeared and it was discovered that the code bases were dramatically different. Weeks of work ended up having to be redone. So they went to check out and lock as the solution.
I don't like check out and lock, because it makes it very difficult for 2 or more people to work in the same project at the same time. Whenever you add a new file of any type or change a file's name, source control checks out the .csproj file. That prevents any other developers from adding/renaming files.
I considered making just the .csproj file as mergable, but the Sourcegear site says that this is a bad idea, because csproj is IDE auto-generated and that you cannot guarantee that two different VS generated files will produce the same code.
My friend (the other developer) tells me that the solution is to immediately check in your project. To me, the problem with this is that I may have a local copy that won't build and it could take time to get a build. It could be hours before I get the build working, which means that during that time, no one else would be able to create and rename files.
I counter that the correct solution is to switch to a mergable model. My answer to the "renegade files" issue is that it was an issue of poor programmer discipline and that you shouldn't use a weaker programmer choice as a fix for poor discipline; instead you should take action to fix the lack of programmer discipline.
So who's right? Is check in - check out a legitimate answer to the renegade file issue? Or does the .csproj issue far too big of a hassle for multiple developers? Or is Sourcegear wrong and that it should be ok to set the csproj file to update and merge?
The problem with update and merge that you guys ran into was rooted in a lack of communication between your group and the consulting group, and a lack of communication from the consulting group to your group as to what the problem was, and not necessarily a problem with the version control method itself. Ideally, the communication problem would need to be resolved first.
I think your technical analysis of the differences between the two version control methodologies is sound, and I agree that update/merge is better. But I think the real problem is in the communication to the people in your group(s), and how that becomes apparent in the use of version control, and whether the people in the groups are onboard/comfortable with the version control process you've selected. Note that as I say this, my own group at work is struggling through the exact same thing, only with Agile/SCRUM instead of VC. It's painful, it's annoying, it's frustrating, but the trick (I think) is in identifying the root problem and fixing it.
I think the solution here is in making sure that (whatever VC method is chosen) is communicated well to everyone, and that's the complicated part - you have to get not just your team on board with a particular VC technique, but also the consulting team. If someone on the consulting team isn't sure of how to perform a merge operation, well, try to train them. The key is to keep the communication open and clear so that problems can be resolved when they appear.
Use a proper source control system (svn, mercurial, git, ...)
If you are going to do a lot of branching, don't use anything less recent than svn 1.6. I'm guessing mercurial/git would be an even better solution, but I don't have too much hands-on-experience using those yet.
If people constantly are working on the same parts of the system, consider the system design. It indicates that each unit has too much responsibility.
Never, ever accept people to offline for more than a day or so. Exceptions to this rule should be extremely rare.
Talk to each other. Let the other developers know what your are working on.
Personally I would avoid having project files in my repository. But then again, I would never ever lock developers to one tool. Instead I would use a build system that generated project files/makefiles/whatever (CMake is my flavor for doing this).
EDIT: I think locking files is fixing the symptoms, not the disease. You will end up having developers doing nothing if this becomes a habit.
I have worked on successful projects with teams of 40+ developers using the update-and-merge model. The thing that makes this method work is frequent merges: the independent workers are continuously updating (merging down) changes from the repository, and everyone is frequently merging up their changes (as soon as they pass basic tests).
Merging frequently tends to mean that each merge is small, which helps a lot. Testing frequently, both on individual codebases and nightly checkouts from the repository, helps hugely.
We are using subversion with no check-in/check-out restrictions on any files in a highly parallel environment. I agree that the renegade files issue is a matter of discipline. Not using merge doesn't solve the underlying problem, what's preventing the developer from copying their own "fixed" copy of code over other people's updates?
Merge is a pita, but that can be minimized by checking in and updating your local copy early and often. I agree with you regarding breaking checkins, they are to be avoided. Updating your local copy with checked in changes on the other hand will force you to merge your changes in properly so that when you finally check-in things go smoothly.
With regards to .csproj files. They are just text, they are indeed mergeable if you spend the time to figure out how the file is structured, there are internal references that need to be maintained.
I don't believe any files that are required to build a project should be excluded from version control. How can you reliably rebuild or trace changes if portions of the project aren't recorded?
I am the development manager of a small company, only 3 programmers.
The projects we work on sometimes take weeks and we employ the big bang, shock and awe implementation style. This means that we have lots of database changes and program changes that have to work perfectly on the night that we implement. We checkout a program, change it and set it aside because implementing it before everything else will make 20 other things blow up. I am for check out and lock. Otherwise, another person might change a few things not realizing that program has had massive changes already. And the merge only helps if you haven't made database changes or changes to other systems not under source control. (Microsoft CRM, basically any packaged software that is extensible through configuration)
IMO, project files such as .csproj should not be part of the versioning system, since they aren't source really.
They also almost certainly are not mergeable.
We use Subversion as our source control system and store the VisualStudio project files (vcproj) in the source control system as is normal I think. With Subversion we don't use any form of file locking, so if two developers are working on the same project at the same time and both add files to the project, or change settings, the second one to commit has to merge the changes.
How do you merge these changes?
The vcproj files are just text files so it is possible to edit them by hand but they are not very amenable to hand editing, especially by junior developers.
The ways I can think of are
Get the latest version from svn and re-add all local changes manually
Edit the file by hand to resolve any conflicts from an automatic merge
Implement some form of locking scheme to prevent simultaneous changes
Have an agreement between developers so they do not make simultaneous changes
Currently we are using the first option of re-adding all changes manually but this is time consuming and I was wondering if there is a better way.
With source files the automatic merge feature works most of the time and we don't get many conflicts.
I've found that option 2 (edit the files by hand) generally works fairly well, as long as you're using a good diff tool (I use WinMerge). The main problem I've run into is that Visual Studio will sometimes reorder the file. But, if you have a good diff/merge tool then it should be able to differentiate between changed content and moved content. That can help a lot.
You might find Project: Merge or Tools for SLN file useful
This is a tough problem and I think a weakness in the Visual Studio architecture. The way we found round it was to not have the proj files in source control at all and to have a build script that handled the configuration settings.
The alternative was very messy and we could not guarantee consistent builds or environments between developers. This led to a huge number of downstream integration problems and eventually we took the draconian step of removing the project files from source control.
The developers environments could still become misaligned but it showed up when they tried to build things themselves.
Using TFS here, but I don't think it makes a difference.
We also don't lock, and sometimes have to deal with merging project files. I've never found it to be that complex or much of an issue. Rarely do we ever experience issues that can't be merged automatically, and the manual merge process is pretty much trivial.
There's only one caveat to this: Check in often! If you make major changes to the project structure and don't check them in immediately those changes can start compounding the complexity of later merges. If I make a major change to the structure of a project, I usually give everybody a heads up. I'll ask them all to check in their current work, and then take care of the merge myself.
I found this recently: http://www.codeproject.com/KB/macros/vcproj_formatter.aspx
If you run this tool on a vcproj file and on a modified version of it then you can merge them together easily with your favorite text merge tool, and in addition the result is a more compact pretty vcproj file.
Options 1 and 2 are not mutually exclusive - if the developer is junior level, let them use option 1 (re-get the project file and re-do the changes) if that's more comfortable for them. For more senior developers, option 2 (merge using a merge tool) is perfectly fine.
I think this is a situation that currently has no magic bullet - sometimes merging is a pain.
We use a diff tool (WinMerge) to merge changes. The project files are (for the most part) really straight-forward XML. The key here, though, is that there never should be any surprises when merging, because good communication is part of the bed-rock of effective source control.
Simultaneous changes to the project are perfectly fine as long as people communicate.