I've got a large Visual Studio solution (dozens of projects; thousands of files) that I don't have the option of reorganizing. I'm troubleshooting a problem and need to switch back and forth between two versions of several files in the solution. Currently the diff between those files are in branch_a and branch_b. As I troubleshoot I may need to commit on either branch, but the changes in either branch won't be in the files I'm concerned about switching back and forth between.
Is there a well-known or straightforward workflow or set of git commands that would allow me to flip back and forth between the two versions of just those couple of files?
If it matters, what I'm switching back and forth between are two versions of a dll of a third party library that are referenced in 3 of the dozens of projects - I'm hoping to avoid going into each project, removing library_a.dll and adding library_b.dll and then the reverse on those projects, so the files that are actually being switched are the .proj files with the differing references.
Obviously (or perhaps not so) non-git solutions to the same problem are also welcome, but since git is tracking the files that seemed like an obvious choice.
Related
So I'm creating my project using a git source control and using some libraries from another repositories. But I'm also developer of this libraries and I want edit/debug them in my project so I can add it to project not alike binary dll but alike another project.
I found this article : Multiple projects in a solution vs. multiple projects in source control
But I'm working on Windows and usually just using Tortoise Git. I guess that will be really hard to configure it such way.
There is another idea. Do not add solution file to version control and create some readme how another developers must construct project and it's dependents.
Maybe someone already met or even solved such trouble, I'm interesting to know any solutions and variants for it.
Thank you.
At a company I used to work for, we ended up putting the projects themselves into different repo's which made managing them easier as opposed to 1 solution. We then wrote a batch file to simply put all the pieces back together and compile it correctly (just compiling the component Projects). This may not work for everyone but it is just a suggestion.
The reason we did this was because opening the solution in VS was getting to be very memory intensive for the machines and was becoming a giant mess of files.
Also this can be used so that teams only work on their specified software and can really only talk to the other components. This is a great way to enforce 3-tier/n-tier architecture design since you separate the projects out and let teams/developers only worry about what they're working on (not really fool proof but it helps).
In our company we usually have a solution consist of several projects, mostly dozen or several dozens. Those are coming from different repos 'cause some of those are general purpose libs, frameworks etc. We, however, use SVN with VS AnkhSVN plugin so there are completely no issues with commiting changes to more than one repo.
My assumption for you is to check whether Git VS plugins could work with seeral repos in one solution. More info on Git VS plugins here: Using Git with Visual Studio
BTW, accroding to 'one or many repos' discussion - we create one repo for a project. So if there are several parts of the project and some of those existed before and will most probably keep being after - those should not be placed in the project repo. Should something great be born within the project and we do believe this will overlive it - we could always migrate repo subtree to an independent SVN repo.
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.
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.
I am working on a large source base (approx 15K files) decomposed into about 25 projects. I want to keep the source in perforce (and am evaluating perforce to that end) but due to complications in the setup it isn't possible for me to keep the visual studio projects in source control, I know in theory the answer to this is to check the projects in, but that isn't feasible (we would end up with projects for several versions of VS checked in, and additionally several variants of each of these, instead they are generated automatically and this setup works very well).
Is there a way to get VS to checkout files for editing as it goes without adding the project to perforce, to avoid the user having to go to the perforce client and manually check out each file for editing as they go? Alternatively (and even better) is there a way to get VS to recognise that the files in a project are under source control, without having to add the project to source control also?
I know we could also take the tack of having every user check out for editing all files they might potentially want to edit ahead of time, then revert unmodified files before submitting their changes, is there a performance penalty in perforce in taking this approach?
In your case, I'd suggest not using the visual studio integration for Perforce.
You can either add Perforce commands to the Tools Menu, or try Nifty Perforce from Google:
http://code.google.com/p/niftyplugins/
One option is to use Perforce as if you were disconnected from the server and reconcile your changes later, rather than telling Perforce everything you do before you do it. (This is roughly equivalent to the workflow in CVS or Subversion.) You would synchronize your working copy, go off and develop, and then ask Perforce to figure out what you did while it wasn't watching.
Perforce has a nice document describing the process: Working Disconnected From The Perforce Server
One thing the document doesn't mention is the allwrite clientspec attribute, which marks all files in your working directory as writable instead of only the files you have checked out.
For the sake of completeness: There is a new tool for your wish called P4VS. I like it better that P4SCC which never worked for me as I wanted.
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.