We are 3 members who wants to work together on a single project
looking for a solution to do so.without overwriting the existing code
Git is your best friend for this problem. Simply nominate the lead developer and let that person create the base application and commit it to the respository to be shared by you all.
The other two members can then clone the repository created by the lead. Each of you will then created 3 branches preferrably in your names where each of your individual work will be saved. After code review of your implementations, you can vote which ones to adopt and merge to the master branch (i.e. the original one created by the lead)
For more info, visit https://www.atlassian.com/git
Related
I did review several of the suggested articles to see if this answer has been given or documented already, but didn't find anything that seemed to answer it.
My boss wants me to create a new Project Folder in an existing Group Project folder ($/GroupProj1/MyGroup/New) and copy all the existing code from an old Group Project ($/MyGroup/CommandProc/Dev) "using TFS" so that the history of each file is preserved, e.g. "View History" of "$/GroupProj1/MyGroup/New/Solution1/NewMe.cs" is copied from "$/MyGroup/CommandProc/Old/Dev/Solution/Me.cs" but retains the history, or at least some link to it's history in the previous solution.
Is that possible?
If so, how? i.e. point me to the right docs, or whatever.
If this has been answered previously, then please forgive my duplication and point me in the right direction.
Thanks in advance!
It's not possible to move source code with history across team project boundaries.
There are some ways you can do it if you don't mind losing some degree of fidelity (such as original check-in dates and the original committer).
The process I've used is:
Use git-tfs to convert the source TFVC repository into a Git repository, containing all of the history
Point the Git repo created in step #1 to the new destination team project and use git-tfs to convert the changes from Git commits to TFVC check-ins, which will "play back" the entire history, one commit at a time.
As stated earlier, you will lose some degree of fidelity in this process. Specifically, the check-in dates for everything will be the current time, and I believe the committer will be the person running git-tfs.
We need to fork our 18 project, 1,000+ file VS2015 C# solution so we can build a similar but different product. Both products will continue to be actively developed.
Changes might be product-specific (of course, otherwise we'd only need one product) or product-agnostic (e.g. payment processing).
I'd like improvements made in either product to be available to - but not automatically part of the other.
I know this could be achieved by manually selecting and merging changesets into the other product, but is there a better way? For example, is there a way developers can mark their check-ins as applicable to both products? Are there any tools I can use to help with this?
Even though Forking and Branching isn't the same! Branching means making a new copy for a new feature and experiments which will be merged to the master later. Forking means making a copy for an independent project.
However, in TFS the branching (from VS or command) is really the only implementation of fork. Detail steps please refer the official MSDN link: Branch folders and files
Note: You can only branch the source Code, not a Project (Work Items, Queries, Reports) though. Those must be copied into the new one.
Where I work, the Kanban is in a different TFS Project than the code (I know...don't ask). Of course, this means the underlying change set & the work item are in DIFFERENT TFS Projects.
Now...
I know merging code between TFS Projects is Baseless & that Baseless merges should be avoided, because, unlike a merge, they disregard the history of either side on the merge.
So my questions are:
Q: Does associating a check-in to a WORK-ITEM in a DIFFERENT PROJECT make it "baseless" in some manner?
Q: Does associating a check-in to a CODE REVIEW in a DIFFERENT PROJECT make it "baseless" in some manner?
Doing so isn't breaking anything.
I get no exceptions, but what is the affect?
Associating a changeset from Project A with a Work Item in Project B is fine. There will simply be a Changeset link added to the Work Item which points to the code stored in the other project. It won't attempt to do any weird merging of the code change into Project B.
Under the covers, a Code Review is really just a Work Item that points to a Shelveset so it's the same as the above scenario, no problem having them in separate projects and it won't affect Project B's source code. The trick here is that you likely want to create the Code Review work item in Project B and the easiest way is to make sure that Team Explorer is pointing at Project B rather than Project A.
Having Work Items and code in separate projects isn't ideal but it is pretty common. Some of the biggest pains I find are:
When you open a .sln in Project A, Team Explorer always connects to that Team Project and you have to manually switch it to Project B where your Work Items are stored.
Where do your builds live? It's easiest to have them in Project A with the code but then you can't see them easily on the Project B dashboard where people will be monitoring project progress.
Test Cases, Reporting and other things have some inconveniences....
If it is confusing for devs, you might want to lock down Project A so that you can't create Work Items in it, then lock down Project B so it can't store any code. This of course, assumes that Project B has no code and Project A has no Work Items.
Hey, it could be worse, WIs and code could be in separate Project Collections :-)
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.
Currently I am working on a project that uses TFS as source control. I am in the middle of implementing a piece of functionality, but am blocked by work that needs to be done by outside resources. Since the functionality is not fully complete, I can't check in the changes without breaking the build. So instead of waiting a couple days while the blocking work is finished, I want to work on some defects.
To do this work in isolation from my other changes, I am working the defects in a second workspace I just created.
After using a second workspace to isolate my changes, a coworker asked me why I didn't just shelve my changes. After doing some reading on shelving, it looks like this is preferred solution to situations like mine. My question is what situations, if any, would you create multiple workspaces and what situations should you use shelving? There are some posts about shelving, but I don't see very much on the subject of workspaces.
By the way, I got the idea for creating a second workspace here.
A new branch would probably be the best way to go. But, to answer your question, one of the key differences between shelving and just using a differnet workspace is that when you shelve, you push your code back to TFS, so it is backed up. Whatever is in your workspace is just what you have on your machine -- if you lose it, it's gone.
We use branching a lot in my shop, and as a result, I haven't seen many uses for shelving.
However, I have found one case where it has been very useful to me:
I often bounce between 2 different development machines (one at the office, one at home, connected via VPN). If I am working on something, and I want to transfer it from home to work, or vice-versa, I often use shelving. I can shelve it from one machine and un-shelve it from the other. I do this when I am in the middle of a change, and checking in would break the build or otherwise interrupt other developers.
You are talking about two completely different concepts here. When you shelve code, you are saving it to TFS, but not checking it in to any particular branch. Creating a different workspace just sets up a new local folder on your development machines and saves the files in your branch there. When you do a check-in, you still could have conflicts.
Why not create a new branch of your code. You can work on that branch and check in without stepping on anyone else's changes, because you are checking in to your own branch of the code. Then, when you have completed your changes, and others have completed their's on the main branch, you can merge your changes into the main branch.
Shelving is the ideal option. Shelving allows you to make changes en masse in TFS outside the regular build, and retrieve them later by name. Multiple workspaces is not a solution for what you're doing. Multiple workspaces are good if you're maintaining different versions of a product and need to work on them, e.g. let's say you have a 4.0 and a 5.0 product and need to apply a security fix to both versions. Shelving is great when you want to make changes but not commit them immediately.