I've been bumping into an issue lately where developers on our team (mostly me) have a tendency to open a project and forget to Get Latest Version before coding and we end up making new changes to old code.
It'd be nice if Visual Studio would know that I'm about to make new changes on old code and either warn me or automatically grab the latest version for me.
Is this possible?
EDIT: I forgot to mention I'm using TFS
Good question, and fortunately for you the answer is 'yes' (since you're using TFS as specified in your comment).
Go to Tools > Options > Source Control (on the left) > Environment and ensure 'Get everything when a solution or project is opened' is checked.
I must add, though, settings like this shouldn't really be used as a substitute for good habits and best practices. You and your team should be aware of the importance of 'get latest' to the point whereby you want to get latest and don't want to work without it (if you're at that stage in the project).
Potential 'downsides' to this:
On the odd occasion, you'll hear our team members say "don't get latest yet". Because of a bad check-in they've made. If they break the build - you'll get that broken build. Not an ideal scenario, it should never happen, but the reality is that it does. You lose an element of that control if it does it automatically.
Not to mention the fact that if your team are forgetting to get latest, there's an even bigger chance of them forgetting to check the changeset for potential issues. The 'resolve conflict' dialog doesn't always highlight every issue you need to be aware of.
I suppose a really minor downside could also be the start-up time of the project (one of the reasons Microsoft more recently got rid of this feature as you mentioned). You're not just opening a solution anymore, you're opening it and waiting for a get latest. Which could, then, require further attention (conflict resolution).
I'm possibly rambling now - but what about when you take on juniors that might not be familiar with source control concepts such as get latest? If it's always been taken care of, they might miss a trick. For example, hypothetically, VS opens but fails to connect to the TFS server as it's temporarily down. Could this cause an already forgetful team to explicitly get latest at a later date?
Related
Sometimes I open a solution, make some change, compile, commit, deploy the software and only later realize that some colleague made a change that is not included in my build, since I forgot to "Update to Latest Version" first.
What I'd like is the following: When opening a solution, AnkhSVN should check whether my version is up-to-date and recommend that I update if it isn't.
I'd send a feature request, but since AnkhSVN has such a lot of features and this is such an obviously useful one (at least to me), I actually assume that this feature is already there and that I missed it when going through the AnhkSVN configuration options.
Is this feature there? If yes, how do I activate it?
This feature is indeed already there. Go to View -> Pending Changes, then click on the clock symbol (Recent Changes). Here check the "Refresh every...." checkbox and select a timespan. Files that are changed on the server and are not updated yet are shown in this view now.
my team uses Visual Studio for our development environment, we like it very much
we use the same project files in our automated build
our problem is that it's so easy to make changes in visual studios UX that get applied to the project files. we're seeing frequent build breaks
...I know...I know... dont submit them to the repro!
I wish I could convince everyone to be more careful, but lets be honest - it's very easy given the number of permutations {x86,x64,any} {release,debug}
My question: Is there anything I can add to a VS project that would make it more difficult to make changes? I'm not looking for a perfect solution, but the UX in VS works great up until a point, and then I'd prefer notepad to keep mistakes down
I could make the file read only, I dont know how that would play with our source control but I could investigate.
I'm hoping for something clever, maybe a mode that would prompt for confirmation before changing?
ideas / tips?
Bring a piggy bank to the office. If a user commits a file that breaks the automated build, then that person has to add $1 to the piggy bank. At the end of the project, or when the pot reaches a particular amount, buy something for the team and print up a sheet showing how much each person "contributed" to the pot.
You should check visual studio for options so that check out and check in are explicit.
You can also add check in policies, which among other can demand that a clean build was done locally before checking in.
If you would like more help, you should add some information both about your current setup and what you would like to prevent and what you would like achieve.
I usually have the team lead check-out the project file and keep it locked. Then nobody else can check-in changes. It is a little lo-tech, but it worked each time we did it. A benefit to this approach is that, when a user tries to make a change to the project file, he/she gets a reminder right away (because it can't be checked-out).
If we need changes, the project lead makes the changes, checks-in and out right away.
I made some changes to my website, then had to reformat my server, and over two weeks I tried to undo what I did (it was a stupid forum thingy). Obviously I missed something, becuase now I have the dreaded Build Failed With No Error problem.
This is my home server, so no I am not running source control.
After staring at it for a few days, I decided to try somehting. Today I allowed VS to run the last successful build, and it still works.
QUESTION: How can I go back to the last successful build? I don't care about any changes made since it worked. That's really all I need.
THANKS
Have you checked to see if you have Previous Versions available?
It sounds like you won't likely be able to recover the source files / project config, though you could certainly attempt to recover the "source" by using tools like ILSpy or .NET Reflector. You can use them to examine the output assemblies, and reconstruct your code if necessary.
As a lesson learned, both Mercurial and Git work wonderfully for versioning home projects - I'd give a slight nod to Mercurial in your case as it works just a tad bit easier on the Windows platform.
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.
I'm using VisualSVN with my Visual Studio 2008 and I have to run some sort of commit monitor in the tray area to see if the local copy of project is out of date.
I have two problems with that:
I hate to have it in two places, I want to see that as an icon in my VS,
The commit monitor software keeps an eye on several projects, when I work on project 1 (which VS knows about), I'm not interested in other projects.
I couldn't find any addons for Visual Studio to do that and was wondering if anyone knows about anything good.
Generally, you have 2 options (besides running commitmonitor as you already do):
run update before you start to change something
ignore it all and merge with any updates when you want to commit.
SVN's really designed around the 'wait until you're ready and merge it all together' model, as there's no guarantee that even if you update your working copy immediately before starting to modify it, someone won't commit changes before you've had a chance to commit. So, let the system do the work for you.
The ultimate alternative if you are worried about conflicts is to use the svn:needs-lock property which means you will have to get a lock on any file you modify before modifying it, and you won't be able to get a lock on a file someone else is modifying.
You might like to ask the VisualSVN people if they'd add an option to check the repository when a project is loaded by VS (or run AnkhSVN and implement this feature yourself).
Work has started in AnkhSVN in this direction, we started to implement the 'Synchronize View' that's also used in Eclipse/Subclipse. The things still missing are: Scheduled checking of the repository, and maybe a notification inside VS to tell you that something has changed.
Right now you can manually refresh this view to see local and remote changes (and merges which can be potential conflicts). Patches are welcome to extend this feature :-)
I'm assuming VisualSVN is your "server" (even if running on the same machine).
AnkhSVN is a good Visual Studio Integrated SVN Client.