I am looking for suggestions on how to best store my Proof Of Concept solutions in source control.
We have many applications each with it's own source control so does it make sense to add a POC subfolder under the root of each application or create a new root just for POC solutions?
We are using Git repositories in Azure DevOps.
Any advice or suggestions is greatly appreciated.
Related
xcode project under version control. multiple developers work on it. when adding 3rd party frameworks i prefere to keep them outside the git repo.
so whats the best practice when it comes to adding a framework (i.e. facebookSDK) to the project?
currently frameworks are "referenced". this way i have a relative path pointing outside my git repo in project.pbxproj...fail.
pretty confident that the answer is straight forward/simple and actually easy to find in the web, but it seems like i'm asking google the wrong questions...
thx.
AFAIK, there are basically two ways to be absolutely sure that a given commit uses a known version of a framework.
Commit the built framework into your repository. This is the common approach.
Use submodules to reference a repository that houses builds of the framework. You'll probably have to create and maintain such a repository yourself.
Option 2 has the benefit of keeping your repository small, but is more hassle, particularly since submodules are something of a pain to work with.
Im trying to migrate from a hosted service to MSFT free Team Foundation Service. However this is causing me more pain than it should!
Im using TFS Integration Tool but im getting conflict after conflict. despite going to an empty TFS project.
Can anyone suggest an alternative approach to this. Im very surprised there isnt an easier option, would welcome all suggestions.
Please note these are hosted solutions that im going from and to and not on prem servers.
Thanks,
Ok so it turns out that the Integration tool wasnt so dumb after all, I was! :) Although I still dont think its intuitive, certainly the whole process could be improved...
Anyway, the conflicts that the tool was presenting me was with the build process templates. Although it is an empty destination project the build templates are created upon project creation.
So I had to cloak this folder and all migrated fine.
Hope this helps someone.
I've been playing with Hudson and got the TFS source control integration running. Problem is: it only allows you to specify a single folder as the source root. We've got a lot of projects that share resources (including standard shared libraries). If I could hard-link a folder like I could in source safe this wouldn't be an issue. I can think of good solutions for other source control systems as well, but sadly I need to work with TFS, and I can't reorganize the folder structure. Declaring things to be built from root would just be too slow.
Anyone any good ideas of how to solve this?
I'm not familiar with TFS, but I took a quick look at Hudson's TFS plugin and it looks analagous to all the other VCS plugins.
Unless I'm missing something, you should be better off setting up multiple Hudson jobs, each with a different TFS source folder, to build each of your projects; you can use inter-job dependencies to control things like rebuilding dependent projects when a shared library changes.
This is a follow-up question to this question.
It's a nice solution to sharing common Views across many projects using source control. However I have a couple of questions, specific to Subversion I think.
Subversion Externals allows you to include a folder from a separate repository in your working copy, so you could define an "External" property on the working copy root that added a folder: [/Web/Views/Forum] for example.
What would happen if you wanted to override one of these views with a version specific to one of the dependant projects?
If you added an additional View in that folder, would SVN commit it to the shared repository?
Is the answer at this stage "wait for MVC2", as I believe it is better for these kind of scenarios?
Thanks,
GC
svn:externals are not the answer to your problem
Just to clarify: when using svn:externals, you're really adding a link to the actual external repository. Whatever you modify/add/delete and commit (given that you have commit access to the external repository) from your working copy will simply get committed to that repository. Everyone else using the same repo (as external or not) will get those changes on a subsequent update.
If you really need to be able to modify the views, you will have to work out a branching & merging scheme I'm afraid. If that is the case, make sure it's really worth the trouble.
EDIT: As an answer to the original question, I think your best bet is to wait for ASP.Net MVC 2. You may want to have a look at this series of blog posts by Eric Hexter, explaining 'Portable Areas' with mvc2 and mvccontrib
we have a solution with multiple projects that is being developed by a team of developers. Project paths in the solution file checked in initially contains the path that are specific to that developer. Now when another dev gets latest of the solution, some of the projects won't load as the path differs.
What's a better way to manage this ?
TIA
When using VSS, I usually have each developer use a local copy of the solution that isn't kept in source control.
The downside is you have to create a new solution from scratch (or use a template from someone else) for each developer that comes on board, but it does address the problem you're seeing.
The simplest way is to dictate where projects/solutions are stored, for example, ensure/insist that everyone stores their working directories rooted at C:\VSS. That ensures that all paths are consistent between developers and stops things breaking.