My current need is to be able to create a new branch from our main branch and open up the new branch solution and work off that.
What is happening, I've added my main source code files to TFS, bound the solution to source control and the application works with no problems. When I create a new branch from the main branch, with the solution from Main closed, then I try and open up the new branch solution, it binds to the main solution not the solution in the new branch. Is there a way around this?
Yes, you could do this as below:
Created a "$/Main" folder
Converted it to a branch
Created a "$/Dev" folder
Branched from Main into "$/Dev"
For example, if your normal workspace maps from "$/Dev" to your local "C:\Dev" folder. And that's where you do your day to day work, and the solution files are under there.
Then when you merge forward to Main, the solution naturally comes with it.The solution doesn't refer to any branch. It contains references relative to the disk location, so it all works in any branch or any machine.
Related
Is there an easy way to move a file to a different folder in dbt Cloud, without having to create a new file of the same name in the new folder, copy/paste from the old file, and delete the old file, which is a pain.
Is there a good reason I should NOT do this? I assume my refs still work as long as the filename remains the same, and I don't have any specific folder logic tied to this file.
For example, say I have my_model.sql in my 'staging' folder and I want to simply move it to my 'mart' folder instead. In this example I'd like to do this to reflect that my file is really a more 'stable' mart-type table file vs a staging view. I realize I can just change the materialization type, but I'm doing this more to organize things clearly. Thanks!
The way to move a file in the cloud IDE for dbt is not 100% obvious. You can use the rename function to move a file to another location.
Click on the drop down next to the file name, then select "Rename." That will open a file path and you can change where the file lives from there by typing in the new folder's name.
The easiest way I have found to do this is...not using DBT Cloud, but using github desktop (no command line needed).
Create a new branch
Open repository in github
View files in your file explorer
Move files or directory locally
Upload to github
Push to origin for the branch you created
Open a pull request
Merge
Depending on what the file or directory is you may find the creating a new branch and opening PR to be overkill. For my specific project there is a lot of legacy organization and models that we aren't totally sure don't have downstream dependencies, so creating a new branch for this allowed me to test run all of our models.
Hope this helps!
I am working in MS Project and frequently move schedules from a share drive to my computer, manipulate and run macros on them, then copy them back up to the share drive.
Generally if I copy all of the subprojects with the Master project at one time the links to the subprojects will update to the destination folder (the one on my computer.) Occasionally I do this and the links do not update, so the Master Schedule is still pointing to the files on the share drive. This causes problems with the macro I then run on it. I have not been able to find anything in forums about this problem.
Has anyone come across this problem? Is there a setting somewhere that is getting changed? Any help would be appreciated.
Yes, I've come across this problem.
The most reliable way of copying a master schedule and all it's sub projects without creating the duplicate links is to:
Select all the files on the share drive
Right click and send them to a zip file
Move this zip file to your local drive
Right click on the zip file and extract all
Then do the same in reverse once you've run your macros. This should reliably copy the master/sub project files with the correct links, without creating the erroneous links you've seen.
We have a need to refactor a code base. The thing is that this will be done by one person and it would be desirable to avoid having the rest of the development team sitting idle while this job takes place.
We therefore tried the following scenario to see if it is possible to work in parallel.
Created file test.txt in directory first in developer A's workspace.
Promoted this file.
Updated developer B's workspace, thereby getting file test.txt
In A's workspace moved file test.txt to directory second.
Promoted this move.
In B's workspace edited file test.txt while it still resides in directory first (no update is made thereby emulating that work is done while refactoring is taking place).
Tried to promote and got a message saying that file test.txt had been modified (correct, file has been moved).
Tried to merge but got an error message saying that AccuRev can't merge since the file is missing in directory second (where it has been moved).
Tried to update B's workspace but that is not allowed since there is a modified file that needs to be merged first.
We are now stuck in a catch 22 situation.
We did try to place a fake file in directory second but that is not being recognized since this file does not belong to the workspace.
Has anyone out there tried something like this and gotten it to work?
It is of course possible to copy files but if there is a better way we would be grateful to hear about this. Or if this is a known bug or limitation in the tool.
We will contact also contact AccuRev support but I thought that I might be able to get some useful tips from the community.
Currently we are using AccuRev client 5.5.0.
Thanks for any suggestions on how to make the tool support this operation.
Referring to your steps 6 & 7: In AccuRev 5.5 after a file is edited and has a (modified) status you first have to keep before you can promote.
At step 8 you could try doing the merge from the Browse Versions view of the file. That way you can select any node to merge with, including the one that has been moved.
Step 9. An AccuRev update will not run successfully if one of the files to be updated is (modified). This is by design. You can keep the file so it has (kept)(member) status then run the update.
David Howland
After contact with AccuRev support the answer is that the only option available is to copy the file to some temp directory, revert the changes, update the workspace and copy the file into the new location in the workspace.
AccuRev will at least tell you which files you have to copy since they will be marked as modified.
I could experimentally verify David's remark to step 9 using AccuRev 5.5.
Let's assume that in the workspace of user A the file was moved and the move was promoted, while in the workspace of user B the file was modified and user B is about to promote his/her change.
Before the file is kept, it will not be possible for user B neither to merge nor to update. But after keeping the modified file the update is possible. The file is first marked as overlap, then the merge succeeds in the new location. Basically, this avoids creating a copy of the file, reverting it and restoring it in the new location after an update, which can be quite cumbersome, as AccuRev does not reveal easily where the move goes.
If user B promotes the modification before user A promotes the move, all goes smoothly, i.e. on update the moved file appears as overlap, but easily merges into the moved file in the new location.
Similar results are obtained when the two users have workspaces connected to different streams and the overlap occurs on a common parent stream. Only if the file is unkept, an error can occur (i.e. only if the move is promoted before the change). Then a simple keep allows to proceed as usual (update, merge, then promote).
I have a build definition in TFS 2012 and its currently dropping the build onto a network share which will be used as the website root folder.
The problem is it's creating a new folder based on the version number each time. I'd like to keep the version numbering but just make it clear out and deploy to the same folder over and over so I don't have to change anything in IIS. Folders are like -
Build20130123.1
Build20130123.2
each containing a complete deployment. I just need one folder that gets everything dumped in it for every build.
What you are trying to do is counterintuitive to the build system, because not only does it drop the artifacts of the build into that folder, but when the retention policy is fulfilled it will try to delete those artifacts back out. So if you do this you will need to set your retention policy to keep always so it never tries to delete out the contents of this folder. You are better off, adding after the copy to drop step a Manual copy to this static folder that won't be subject to retention policy as it will know nothing about it. But if you wish when you open the template in the main sequence you will see a sub-sequence called Update Drop Location. In there is 3 items, the middle one is an If statement for if drop build and Build Reason is triggered, dig down into the then side and you will find a sequence which contains an activity called Set Drop Location. Right click on its properties and you will see how the path string is currently put together, adjust this string to what you wish and then this value will be propagated through out the build template
You could use the new feature in 2012 sp1 that lets you place the output within TFS source control then you would just need to run a TFS GET command manually or via an updated workflow call to update the latest files and binaries for your website location. Option number 3 in the picture below.
2012 MSDN-Select a Staging Location and Setting Up a Drop Folder
In Team Foundation Server 2010, I have created a source control branch for a major project that I want to be temporary. After the project is closed, I'd like to tie off the temporary branch, merge it into my Main branch, and then delete it. I want to delete it simply so I don't have a temporary branch hanging around for all time. BUT, I don't want to lose the check-in history from this branch.
So, my question is can I delete a branch that has been merged into other branches without deleting that branch's history as well?
Deleted branches are basically hidden, not really deleted. This means they don't show up in Source Control Explorer (unless you have the show deleted files option turned on), but the history for the branch should still be available via the annotate tool and when viewing history on a file in any branch you merged the branch back into.