Disclaimer: I'm stuck on TFS and I hate it.
My source control structure looks like this:
/dev
/releases
/branches
/experimental-upgrade
I branched from dev to experimental-upgrade and didn't touch it. I then did some more work in dev and merged to experimental-upgrade. Somehow TFS complained that I had changes in both source and target and I had to resolve them. I chose to "Copy item from source branch" for all 5 items.
I check out the experimental-upgrade to a local folder and try to open the main solution file in there. TFS prompts me:
"Projects have recently been added to this solution. Would you like to get them from source control?
If I say yes it does some stuff but ultimately comes back failing to load a handful of the projects. If I say no I get the same result.
Comparing my sln in both branches tells me that they are equal.
Can anyone let me know what I'm doing wrong? This should be a straightforward branch/merge operation...
TIA.
UPDATE:
I noticed that if I click "yes" on the above dialog, the projects are downloaded to the $/ root of source control... (i.e. out of the dev & branches folders)
If I open up the solution in the branch and remove the dead projects and try to re-add them (by right-clicking sln, add existing project, choose project located in the branch folder, it gives me the error...
Cannot load the project c:\sandbox\my_solution\proj1\proj1.csproj, the file has been removed or deleted. The project path I was trying to add is this: c:\sandbox\my_solution\branches\experimental-upgrade\proj1\proj1.csproj
What in the world is pointing these projects outside of their local root? The solution file is identical to the one in the dev branch, and those projects load just fine. I also looked at the vspscc and vssscc files but didn't find anything.
Ideas?
#Ben
You can actually do a full delete in TFS, but it is highly not recommended unless you know what you are doing. You have to do it from the command line with the command tf destroy
tf destroy [/keephistory] itemspec1 [;versionspec]
[itemspec2...itemspecN] [/stopat:versionspec] [/preview]
[/startcleanup] [/noprompt]
Versionspec:
Date/Time Dmm/dd/yyyy
or any .Net Framework-supported format
or any of the date formats of the local machine
Changeset number Cnnnnnn
Label Llabelname
Latest version T
Workspace Wworkspacename;workspaceowner
Just before you do this make sure you try it out with the /preview. Also everybody has their own methodology for branching. Mine is to branch releases, and do all development in the development or root folder. Also it sounded like branching worked fine for you, just the solution file was screwed up, which may be because of a binding issue and the vssss file.
#Nick: No changes have been made to this just yet. I may have to delete it and re-branch (however you really can't fully delete in TFS)
And I have to disagree... branching is absolutely a good practice for experimental changes. Shelving is just temporary storage that will get backed up if I don't want to check in yet. But this needs to be developed while we develop real features.
Without knowing more about your solution setup I can't be sure. But, if you have any project references that could explain it. Because you have the "experimental-upgrade" subfolder under "branches" your relative paths have changed.
This means when VS used to look for your referenced projects in ..\..\project\whatever it now has to look in ..\..\..\project\whatever. Note the extra ..\
To fix this you have to re-add your project references. I haven't found a better way. You can either remove them and re-add them, or go to the properties window and change the path to them, then reload them. Either way, you'll have to redo your references to them from any projects.
Also, check your working folders to make sure that it didn't download any of your projects into the wrong folders. This can happen sometimes...
A couple of things. Are the folder structures the same? Can you delete and readd the project references successfully?
If you create a solution and then manually add all of the projects, does that work. (That may not be feasable - we have solutions with over a hundred projects).
One other thing (and it may be silly) - after you did the branch, did you commit it? I'm wondering if you branched and didn't check it in, and then merged, and then when you tried to check-in then, TFS was mighty confused.
#Kevin:
This means when VS used to look for your referenced projects in ....\project\whatever it now has to look in ......\project\whatever. Note the extra ..\
You may be on to something here, however it doesn't explain why some projects load and others do not. I haven't found a correlation between them yet.
I think I'll try to re-add the projects and see if that works.
#Cory:
I think that's what I'm going to try... I have about 20 projects and 8 or so aren't loading. The folder structures are identical from root... ie: there aren't any references outside of DEV.
Related
At my workplace, I have managed to install and use locally Tortoise svn, to easier trak the implementation of the tools. For the new projects, it's easy because I start from scratch with the version control.
Now, for the past projects, I have copied the entire folder to keep a versioning.
It looks like this:
TempProject 20.07.2017
TempProject 21.07.2017
TempProject 22.07.2017
....
Is there a possibility to integrate all this changes with Tortoise?
Meaning , I want to have a base, than commits, for each version
Thank you...
I have managed to solve it.
I copied, one by one, the content from each folder (TempProject 22.07.2017 etc.) into my working copy folder, then I opened the project and committed the changes.
Maybe it's not the most efficient method, but at least it wasn't very complicated
I am about to start participating in the development of a medium-sized project (~50k lines) that was until now written by a single person, and not versioned; as a result folders are cluttered with different versions of the same file (named file1, file2, file3, etc.).
I proposed to start using a VCS for it (a priori Mercurial, which is the only one I've ever used -- for my personal projects --, but I'm open to suggestions), so I'm taking any good ideas as to how to "start" the repository. E.g., should I make an initial commit with all the existing files, and immediately make a new commit with the unused files removed? Or something else?
(constructive remarks on mercurial vs bazaar vs git vs whatever are also welcome.)
Thanks for your tips.
E.g., should I make an initial commit with all the existing files, and immediately make a new commit with the unused files removed?
If the size of the repository is not a concern, then yes, that is a good starting point. Otherwise you can just commit what's actually used, and go from there.
As for which system, all DVCSes stick to the same core principles. Which one you pick is entirely subjective — the only way to truly know which one you like is to try each one.
I would say use what you are the most comfortable with and meets your needs. As far as where to start, I personally would seed the repo with the current source as is, that way you can verify that everything builds and runs as expected. you can make this initial seed a branch. That way you can always go back to your starting point before refactoring.
My approach to this was:
create a Mercurial repository in the existing project folder ("existing")
commit all project files to "existing"
create an empty repository in what a different location ("new")
As files are tested and QA'd (this was necessary because there was so much dross in "existing") pull them from "everything" to "new".
Once files had been pulled into "new"; delete the corresponding files from "existing". If access is needed to these files while the migration is under way, push them back from "new" to "existing".
This gave me the advantage of putting everything under some sort of control for recovery purposes, control over introducing the project to the DVCS. Eventually the existing project folder became completely tested and approved for the project moving forward. At this point the "everything" directory could be deleted or changed into a working folder; and "new" became the actual project folder.
I think Mercurial is a good choice. Lightweight, fast, very simple to use and well-integrated with Windows (if that's the platform you're dealing with).
I would probably get rid of all the clutter before the first commit. Delete everything you don't care about, run all the necessary tests and only then do the commit.
Yes, I'm dead set against the 0-day cluttering of repos.
Granted, a 50K SLOC project isn't very big, but if you commit files you already know you won't need, they will make your repo slightly bigger.
Also, remember to check that the tree doesn't contain large binary files. If it does, get rid of them if at all possible.
Each time I do a commit in Xcode I notice that the AppName.xcodeproj file/bundle has been modified. The modifications are obviously important although I don't have enough experience with Xcode to understand them.
What strategy should I use for this? Do I simply commit these changes each time? It's no big deal, it's just that it will appear in SVN history. I'm assuming that I don't add an 'ignore' SVN proprty for this file/bundle, right?
That project folder contains the metadata for your project, so it certainly needs to be included in source control. There are a some user-specific files you can leave out, though. My .gitignore includes these two entries
*.mode2v3
*.pbxuser
But it won't hurt to leave them in, since they don't affect anything when other users open the project.
I have followed this article for every project and it helps me extremely well. You have to commit two files: .gitignore and .gitattibutes first in order for GitX to have effect.
You'd better to add build directory in order not to include temporary binaries into the repository.
As of late, my team and I have been hard at work turning our inherited source code into something we can live with. Part of this process is to make the source control image look a little more like what most people might expect to find when browsing a repository.
The original structure contains a branch called "Branches", the contents of which are what one would find in a "Tags" folder in systems like Subversion. Since "Branches" is a bit too non-specific for my tastes, I wanted to change it to "Tags" -- but it would seem that I cannot do that unless I create a workspace mapped to the root of the repository and then create a working copy from it. On this project that is a huge file transfer (lots of old tags).
Please tell me that I have just overlooked the obvious and should really spend more time reading the instructions. Is there no simple way to do this without pulling everything to the client first? I really enjoy most aspects of TFS, but this is something that would have taken 15 seconds or less in Subversion -- so I hope I'm just missing something.
Thanks in advance to any responders.
You don't need to get the whole folder but you need to get the folder itself. You can't do this from within the IDE but you can from the command-line:
tf get c:\dev\
Because we haven't specified the /recursive option it will only get the immediate children of c:\dev\, which would be folders such as trunk and branches.
For there you can rename the folder:
tf rename c:\dev\branches c:\dev\tags
And then check-in the rename.
Regards,
William D. Bartholomew (Team System MVP)
What I currently do is I link the project to another location and give it the same name, then check the box where it says "Branch after share."
And then I would Check out the shared project and work off it. And finally merge with the original project.
This works okay, but it feels very clunky: I have multiple instances of the project on my drive; I have to change physical address of the website (i use asp.net 1.1) every time I work on a different branch;
That doesn't feel like the right way to do it. How do you branch your projects with VSS?
I think the way you describe in the question is the only way you can do it in sourceSafe.
I usually name the copied directory "V1.0" (or whatever is appropriate) and keep them all in a folder that is the main project name.
That is the generally accepted way of branching your source code in SourceSafe. The only other way to do it, if merging and retaining the history are not an issue, is to copy the files to a new folder, remove the read-only attribute, remove the .vssscc and .scc files, and then add that new project to SourceSafe. At that point, you have an all new project, with no prior history.
You can find a good reference here: http://www.codepool.biz/version-control/sourcesafe/branch-in-sourcesafe-vss.html
Basically right-click-drag your folder to where you want a branch, and when you let go you are given share/branch/recursive options.
Shudder.
The way you described is the only supported way to do "branching". And as you pointed out it is rather clunky. In VSS it's best to avoid branching alltogether as it will destroy your source history.