I am currently working on Phase 1 of my project and all files are checked into Visual Source safe. How do I version this project as phase 1.
I know if it is a single file we can roll back changes etc.
After I start working on Phase 2. I should be able to get the phase I project and make any changes as required.
Please help
If you want to make changes to both Phase 1 and Phase 2, your only option is to make a copy of the entire project.
If you don't need to go back and make changes to Phase 1 and will only ever need to get the code for it, you can use a label.
VSS has a feature called "Share and Pin". It is the closest thing it has to branching. I've found it to take a long time, slows down access later on, and hard to work with.
But I would suggest starting by looking in the help for that topic.
Introducing Visual SourceSafe
How to: Share and Branch a File
Related
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 often need to return to a previous milestone.
There is a vicious cycle: my error is revealed only during debugging, but I can't step back because the debugger has saved my project.
In simple projects I always used to make a copy of my cpp file (just keep ctrl and drug your file a bit).
But now projects has become more complicated (with header files).
I have tried to use save solution as. But it seems as if it is just renaming the sln file without making a copy of the whole project.
So, what shall I do? Copy the whole project as I did with the file?
The question seems a bit clumsy but it really troubles me: what elegant decision is there?
You can use software versioning systems like SVN or Git to undo the savings and return to previous point in your project, also there are some extensions for visual studio like ankhsvn and Gitextention that you can use.
If you are using vs 2010, you can disable saving on build event from Tools>Options>Projects and Solutions>Build and Run
Usually when I start a web site project and build on it over time, every time I want to save my project, I save it and keep a copy of that saving that consisted of all project files in a .rar file and keep a lot of Incremented saving .rar files , I do it because I could possibly mess things up and sometimes I run out of idea what went wrong, so that previous version of my web site project will help me have a return point to where things were OK.
I'm not sure if it's the best approach for this purpose, I was wondering if there is any tools or extensions to make it easier, so every time I save my project that extension or something do it for me, or is it any better approach to do this that I'm not aware of?
The best approach is version control. Look at svn or git for instance, there are also VS extensions so you can use them from within the IDE if that is what you are after.
Anyone had any success getting SVN to merge Visual Studio project (.csproj) or solution (.sln) files that have been edited by two users? Example
User A checks out project
User B checks out same project
User A adds a file
User A commits changes
User B adds a file
User B commits changes
Seems to me that at step (6), svn, Tortoise, Ankh or whatever should detect a conflict and either merge the two project files automatically or, more likely, prompt User B to resolve the conflict. Currently, we're seeing changes made by User A obliterated when User B checks in, resulting in bad builds, deploys, etc missing features that had been added before the last checkin.
Since the project files are XML, why is this an issue? Am I missing something here? I've searched the archives here and googled to I can't google no more, but haven't come up with a good solution.
How do you think you trick SVN into performing step #6? It seems you misunderstood what goes wrong. SVN will never ever commit from a working copy that's not up to date, so step #6 won't work without user B previously updating and merging user A's changes. Honestly. Try it.
I guess what happens instead is this:
A checks out project.
B checks out same project.
A adds a file.
A commits changes.
B adds a file, but forgets to save the project/solution.
B tries to commit changes and gets a message he should update first.
B updates.
B switches back to VS. VS tells him the project/solution changed on disk and asks whether he wants to a) reload from disk and lose his changes b) override the version on disk.
B doesn't understand, doesn't try to understand, considers his changes valuable, and picks b), overriding the changes on disk.
B still doesn't try to understand and thus does not diff the version he has on disk with the last committed one and thus misses that he overrode A's changes.
B Checks in, overriding A's changes.
I've seen this happening once in a while, usually with a user B who does not really understand SVN's (or CVS', FTM) workflow.
So here's a few hints:
Don't update unless you have saved everything ("File"->"Save All"; for me, that's Ctrl+Shift+S). In case you have made that mistake and you're stuck, do override the changes on disk and then merge the lost changes manually. (It might also work to update the project/solution file back to version N-1, and then to HEAD again, in order to have SVN perform the merge.)
Don't commit without checking which files you changed and having a quick look at the diffs to see whether the changes are what you expect.
Commit early, commit often. The more developers work on the same code base, the more likely you get conflicts. The longer you change your working copy without updating, the more likely you get conflicts. Since the number of developers usually is out of your hands, the update frequency is the one thing you can use to reduce the probability of conflicts.
I second sbi's answer. One possible solution is to always update from within Visual Studio, at least if you use VisualSVN (I'm not sure how AnkhSVN copes with this situation).
VisualSVN will block visual studio during the update operation, and make sure any changed projects are automatically reloaded, so users can not ignore the external changes.
A rather radical but efficient solution is to use a tool to generate those solution files from a meta-definition and then putting only the meta-definition under source control, not Visual Studio project files (which are a nightmare to merge).
In my team we use MPC to do this. We have:
a bunch of .mpc files for project descriptions,
a .mwc file for workspace / solution description,
a small .cmd to generate Visual Studio files.
Since they are all hand-edited text files, we no longer have problems with Visual Studio mixing up everything.
The drawbacks are an extra-tool and the need to regenerate the solution files when files are added or removed but there are some additional benefits too:
project configurations are centralized: for instance, changing a compilation flag is done in a single place instead of on a per-project basis,
this can accomodate multiple build systems (we currently use Visual 2003 and 2005 but this also works with gcc and others).
From my experience, althgough setting up the tool can be a bit painful (but it all depends on the size and complexity of your project), this is clearly worth it.
Note that MPC isn't the only tool for this purpose. Others exist, such as CMake.
You can also try to reduce conflicts by ensuring that your project files don't list every individual file inside the project. This will avoid the project file from being changed in first place when a user adds a file.
You're free to use wildcards inside a project file: see MSDN
Example:
<ItemGroup>
<Compile Include="Src\**\*.cs" />
[...]
</ItemGroup>
It is sad that Visual Studio doesn't encourage this kind of project setup and instead opts for listing individual files.
This is very tedious and tiresome so you just have to plow through it. You will sometimes keep the local working copy since it has all of your custom projects added. However, in other cases you will want to merge in all new items from the Base solution so you end up with everything from both solution files. For readability it is best to place all base product additions before customization additions.
Do not worry that the first portion of the GUID is identical for projects, but it is the last portion that will be unique.
Fissh
I hope this qualifies as programming related since it involves how to structure a project.
Because I've always used the web site model with VS.net I never had solution and project files and putting everything into source control worked great. I knew that everything I had in my web site directory was all I needed for the web site.
Now I'm using asp.net MVC and it only has a project model so now I have these solution and project files. If I work on it alone it's fine but once other people start to add/delete files from the project our solution file gets messed up and people end up having to grab the latest solution file, see what got changed and then add back/remove their files and check in the solution file again. It's become sort of a problem because sometimes people don't realize the solution file was changed, they make other changes and then when they check in everything other people do an update on their files they find that their files are gone from the project (although still physically on disk).
Is this normal? Is there a way to structure a project so that we don't need to check in solution and project files?
Your developers are not using TFS correctly. You should have multiple check-outs turned on, and everyone needs to be careful to merge their changes correctly when checking in. TFS will prompt you to do this, and accepting the defaults is nearly always the right thing to do.
It's not uncommon to have one or two developers who never get it, and you might have to help them now and then. But every programmer who works on a team needs to learn how to use source control tools correctly. If they can't manage that, they shouldn't be writing software.
[edit] It occurs to me that you might run into these problems if you check in the *.sln file directly, rather than choosing to "Add Solution to Source Control".
I don't think it's normal - what are you using for source control? It sounds like developers aren't respecting changes that others a making - checking in without merging first.
I know that early on in a project, when lots of files are being added & deleted, it can be a problem to keep up - you need to check out the project file, add your files, then check in the new file & project so other developers can also update it. You'll probably have multiple project files in a solution - perhaps one interim solution would be to have one "holding" project for each developer, then clean them up periodically - though these types of temporary fixes do have a tendency to become permanent.
I don't know of a way to set up a project file that's not in source control, though I suppose you could create a script that would generate them.
Having been through this, the key is respect & good communication between the developers.
This tends to happen with TFS multiple check outs. It can be hard to grasp coming from VSS to TFS as VSS allowed one person to check a file out at one time. Auto-merge should work most of the time for you but a couple of rules should ease the pain:
Check in early and often (if you add remove or rename a file check it in straight away even if it is a blank holder)
Before you check in do a get latest, this will ask you to resolve conflicts locally
Try to get continuous integration set up so that developers always know the state of the buidl and whether it is OK to check in\out.
We had a bit fo pain at the start of our current project but it soon settled down when we followed the rules above.
Personally, I think making changes to project and solution files requires discipline and clear (well understood) rules throughout your development team. These files (.sln, .*proj) are the bottlenecks of your project, and any errors or inconsistencies can cost you in team downtime. Changes need to be well thought out, planned and then executed.
They must be secured by source control (which you're already using, excellent) and your team members should work on the basis of only making the changes they need, and not leaving project or solution files checked out for an extended period.
If you are allowing multiple (shared) checkouts, this could become problematic in terms of overwriting another user's changes. Depending on your source control mechanism, people may be required to manually merge changes. Personally, I'd ask people to negotiate their project/solution changes with each other over merging (this can't always be achieved).
A third option if you are using TFS is the shelve feature. If someone needs to make changes locally, they can shelve the changes and merge later.
Lastly, another strategy is to try to architect your solution to be as modularized as possible - so people are distributed, working on separate projects and do not (ideally) have to overlap on too many common areas.
I'm not sure if you are using TFS, as people have mentioned, but if you are (or if you are using source control with similar capabilities) you can set it such that sln and csproj files are exclusive lockouts and are not able to be merged.
We have done this with quite large teams and while it causes some initial issues as people get used to it in the long run it has resolved many issues that were previously causing problems. Essentially you trade longer term merge issues/complexity for short term compile/checkin issues which we have found to be a good trade off.
Once you have set it to forced exclusive checkout and no merge you then get your dev teams used to the fact they should keep locks on the sln and proj files for as shorter time as possible.
Always check them in.
Always check out latest (merge if possible), make sure your change is there, before checking in a new version.
If your source control doesn't require a special action to check in from an old version, GET A DIFFERENT SOURCE CONTROL.