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.
Related
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
I've got a bit of an interesting project layout question for you all. I'm really not sure how to handle this, so I'm hoping someone here has a bright idea.
Basically, I have a Web Application that for the most part, is the same per customer (except the configuration files). There are certain files that are different for each and every customer (javascript, css, sql snippets), and managing all this is a bit of a pain with the setup we have now.
Currently, we have all these customised files sitting in the SVN repo and when someone comes to make changes, they first check out the core project (Web Forms Application consisting of pages, C# classes, javascript files, global styles, images, etc.) into a new working directory, then check out the customised files and export them into the working directory of the core project. Once they've finished making changes they will commit any changes that happened in the core project (bug fixes, changes/features other customers will want), and then copy back the customised files to the customised working directory and commit that. Needless to say, it's a major pain and things get missed.
My end goal is to have a single working directory for the core project (excluding any special development branches), and a customised project per customer. The developer would have a solution file that has both of these projects as part of it, they can make changes to either, and commits would go to the right repos.
Now, I could set up a multi project solution that looks like this, but functionally I have no idea what to do. How can I run the core project and have all the customised files available? How do we deploy to a testing or production server? How do we handle things like the web config that are only partially customised (e.g. connection strings)?
If anyone has worked on something like this, or has an idea on how we could set up a project like this, it would be greatly appreciated.
Ok, my working place experienced the same problem before. We ended up using branch.
Say you have 2 projects in one directory (main), and now you have another client coming in.
Simply branch this directory (main) to another directory (clientA). Now in directory clientA, you should have 2 projects.Do your daily development as usual, but just merge in the changes in core project to main branch.
---Main
----Core
----CustomisedSkeleton
---ClientA (branch)
----Core (do merge back later)
----ClientACustomised (client based code, do not do any merge in)
One morething, since your work is web applicaton, you need update each branchs' web projects file, to make it binding to different URL on your local IIS.
Say main webapplication's url is "http://yourmachine.com/main/login.aspx",
and you customised branch's web application url is "http://yourmachine.com/clientA/login.aspx"
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).
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 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.