I work on several different software projects and I started building up some generic libraries with utilitarian functions that I use in all of them. Recently I had three or four projects going at once at different physical locations and it got painful to synchronize the libraries manually.
So I figured I should create a repository for these libraries so I can access them from anywhere. I'll sit down one final time to synchronize them between projects, commit them, and from now on I'll have the repository to make sure I keep things straight and keep the most recent version of the library working with all the relevant projects.
Because I'm working in Visual Studio 2010 I went with AnkhSVN. To my dismay, it does not seem to allow you to manage only projects within a solution---only the entire solution!
I go by the instructions here; they're pretty clear. There is some minor confusion in that an SVN "project" is not a Visual Studio "project", apparently.
So I select a project in the Solution Explorer, right click on it, and select "Add Selected Projects to Subversion...". The window that pops up uses the solution name for the field labeled "project name". That's a sign of trouble, but I can manually change it to be the actual project name. Then I can choose a repository, and create a folder for this project. So far so good.
But then for "local folder" it's a drop down list with the default selection being the location of the solution, and the only other options are moving farther up the tree. If I leave it as is and hit OK, AnkhSVN wants to put the entire solution in that directory I created (assumingly only for the selected project).
In fact if I select "Add Solution to Subversion..." I get an identical window.
I want Subversion manage only certain projects within a solution. With local solutions, that's how I make sure I keep my libraries universal; instead of just linking to the build I add the entire source to each solution so changes are "global". Now I need to do this for solutions at physically different locations and apparently AnkhSVN won't let me do this? Is it broken or is this by design?
There is no 'standard' way of providing a UI to handle this situation, but if you just checkout your working copies and bring all of the projects in a single layout AnkhSVN will just provide all the tools to work on this project.
The really hard problem -where we as AnkhSVN team are working on- is how we can provide the necessary UI to work with this kind of layouts easily. There is no easy way to layout your project if it is made out of different trees that live in different parts of your harddrive.
A workaround for some projects might be to create a parent working copy with externals (svn:externals) pointing towards the separate projects. In that case checking out the rooot project will automatically bring in the other projects.
It looks like this has been known since 2008 and the developers don't think it's important enough of an issue.
http://ankhsvn.open.collab.net/ds/viewMessage.do?dsForumId=582&dsMessageId=152095
You can proceed in this way.
Before make a solution with all projects follow the steps.
For each projects add them separately to svn (each projects with
it's own directory structure in svn)
Make a solution
Add each desired projects to solution.
In this way you can commit changes just to desired project and commits are not bundle to solution.
Later on you can easily separate projects from solution (delete, move to other solutions, etc).
Related
I have read FAR too many posts on SO and I am now in analysis paralysis!
I work with Visual Studio 2010 and I have many small projects, many of which reference library/shared projects.
I don't really mind about having to check/re-build dependent projects if I make changes to shared code...I'll be putting TeamCity in place ASAP to assist with this, but for the moment, I just amend the code next time I work on a project. Many projects are "write once and forget", so they'll never need updating.
The team is very small at the moment (ME!) but new devs are expected early this year, but it will still be a very small in-house team, with fast project cycles if that makes any difference.
At the moment I have a very flat folder structure on disk, so ALL of my sln files are in a "development" folder on disk. Then there is a folder per VS project. This makes sharing pretty simple, and also leaves me with a single packages folder for nuget.
I am about to import everything into SVN (VisualSVN) and I'd like to start adding things like database scripts, docs, UAT tests, etc. etc.
Do I keep my flat structure and have a single trunk/branch/tag at
root level?
Do I expand the structure to an SVN folder-per-solution
and then have trunk/src, trunk/docs and manage things like nuget
packages with svn:eternals?
Do I hybrid this and have an SVN folder-per-solution but with docs in the VS solution?
NOTE: I am putting in SVN so I can bring in some Java development but keep source code managed in a single way. We will also share with a DB team, who want to put docs/sql sripts etc in there. I intend a separate repository each for DB and Java - but would like a "similar" folder structure for each of them.
NOTE2: I have some SVN user experience, but no Admin experience. The new devs have no experience at all (they are coming from an AS/400 background) so the simpler the solution the better! I've looked at repo per project and svn:extenals and whilst it is a great solution, it will require me to manage and maintain all the time (as well as do my own work! lol)
ANY advice from people who have "Been there, done that-GTTS" is very gratefully received.
OK, I now have the following local solution structure:
ALL my sln/suo files are in the same folder.
ALL of my project folders/files are subfolders
This makes sharing projects easy enough...but looks very messy and is hard to find anything :(
Should I be using svn:externals to manage "reference" projects, so I can branch/tag them?
Should I only reference built DLL's - and all the management that comes with doing that?
Should I let VS2010 manage my folders, and not care that I have lots of "nuget" folders etc.?
VERY VERY confused now...any decent answers? :(
NOTE: Will be adding TeamCity (or something similar) to the mix ASAP to provide CI capabilities. Any serious (and FREE) recommendations for CI also appreciated.
Here is a structure I use at work and for personal projects:
SVN structure:
root
shared_code
productA
trunk
branch_of_shared_code
productA projects
productA solution
branches
branch1
branch_of_shared_code
productA projects
productA solution
tags
...
productB
...
Periodically (when exactly depends on your needs) all changes from the main branch of shared code are merged into product's branches of the shared code. Changes to the shared code are either made in product's branch and then merged back, or in the main branch and then merge to products.
Product sources content:
Everything needed to build the complete package is considered as source. E.g. if you have DB scripts - they are part of sources. Tests - too. For documentation I usually add a separate project into the solution which contains all sources for building documentation and produces result in the output directory. Then a project creating installer will include it into the generated distributive.
Planning:
This may be debatable, but I prefer to store tasks list next to sources and branch/merge them together. If a task is completed in a branch, it's not completed in trunk until merge. More general planning may or may not be appropriate for storing next to the sources.
On disk:
First of all I believe in working with repository in such a way that it's OK to not store working copies for every product, but check them out on demand. Of course, checking out/deleting working copy for every change is impractical, so I have a directory for every product which I'm working frequently at this time, inside of it I check out branches I work on (trunk and some others). The rest of products need not to be checked out if you don't expect their development soon.
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 know this is possible because one of my older solution files has a mix of some projects under source control and some not.
However I can't seem to reproduce that configuration with a newer solution. Every time I add a project to the solution it acquires a yellow cross and under Pending Checkins the project is listed as a Newly added file.
This is with the Perforce plugin for VS2008.
I have tried adding a brand new project, vs an existing project. I have tried p4 obliterate. I have tried disconnecting and reconnecting source control. Binding and unbinding.
After all this, every time I try and add the project it gets a pesky little yellow cross. I can't seem to tell Perforce and VS that, while I do want source control on the majority of the solution, I don't want this one project file under source control.
I see now that the way to have multiple projects under one solution, some projects under source control, and others not ... is to avoid having the solution itself under source control. That way I get just the projects I'm interested in checked in and out and the rest ignored.
Which, in fact, on closer inspection, is how I've managed (by muddle, mistake or design, I can't remember) to solve this in the past.
Under File, Source Control, go into the Bindings dialog. Click the project in question and unbind it. You can leave the other projects, and the solution itself, bound to source control.
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.