I have the following TFS configuration
Root\
Proj1\
App1\
...
App2\
...
Proj2\
Lib1\
...
Lib2\
...
App1 and App2 both have project references to Lib1 and Lib2.
App1 does not reference App2, and Lib1 does not reference Lib2.
Now, I want to make changes to Lib1... but I want to branch it because the changes are drastic. These changes shouldn't require changes in either app1 or app2.
I created a branch Lib1Branch1 in TFS... but App1 and App2 both still reference Lib1 rather than lib1branch1... I don't want to manually re-reference the branch in each App (In actuality I have much more than just two).
When I used SVN, if I branched a project, and switched to that project, the local folders kept their original names and only the contents changed... thus building with one branch of the lib vs. building with the other only required that I switch branches and do a get-all... how do I get similar behavior using TFS?
I think you have a misunderstanding.
A Project is a self contained piece which is part of a larger thing called a solution. For example, a single class library is one project. It may reference other projects.
There are several ways to do branching. Minor branches might just require branching a particular project within the solution (such as Lib1) while major changes might require branching the entire solution.
It sounds like what you need to do is change your TFS structure slightly, then branch the entire thing. For example, the folder structure should probably be similar to the following:
Root
\1.0
\Web Apps
\App1
\App2
\Libraries
\Lib1
\Lib2
Then, when you branch, you take the entire 1.0 branch. That way all references are preserved between the two branches.
Related
We are starting a new project using angular2, typescript and gulp. For the time being our application will consist of two subprojects: a components library (which in the future might be spun off into a separate project) and the app using the component library.
The layouts of the project is going to be something along the lines:
/project_root
/component_library
/src
/library
/components
/services
... etc
/application
/src
/app_name
/components
/services
... etc
The components in application will be using components from the library (but not the other way round)
We would like to have clean (non relative) imports in the app components when importing stuff from the library (we want to avoid ugly imports of the sort '../../../component_library/src/library ...etc' plus, what's more important, we want to be able to move the library code to a separate project without the need to update imports.
There are two possible solutions I see (don't like any of them):
Add a gulp task that would watch the component library and on every change copy the file to node_modules in /project_root
Some sort of simlink? so that we can point /project_root/node_modules to /project_root/component_library/src?
I'm afraid the first solution might not work well with IDE autocomplete in the application (first gulp would need to do the compilation/copying then the IDE would need to pick up the change from node_modules - this looks like something that can be really slow)
The second solution feels hacky - it would need to be repeated by everyone who checks out the code from repo.
What would be the best solution here?
what's more important, we want to be able to move the library code to a separate project without the need to update imports.
Ship your component_library with source and add it as a node_module dependency. Then when someone pulls your code they can add a git remote to node_modules/component_library code and work on the two projects seemlessly.
This is the approach I took with ntypescript.
Maybe some Perforce gurus could provide some advice.
We have a depot, with a setting.xml file in central folder:
///depot/central/config/setting.xml
and would like it to be instanced in several locations, like:
///depot/projectA/tool1/config/setting.xml
///depot/customerB/tool2/config/setting.xml
The benefit is for maintenance. the setting.xml file only has to be updated once in //depot/central, then all files in the other places get updated as well, so we don't have to get into each place, duplicate it again and again.
AlienBrain has a feature called 'shortcuts', does Perforce have something similar?
We've tried use the OS' symbolic links feature, but it didn't behave the way expected -- cloned files still need to be checked-out first, then check them in again -- this makes the cloned files own their own revisions against the original one.
It's better to just keep the original and cloned files have the same revisions. so if submitting a new revision to setting.xml(5/5)(which makes it to be setting.xml(6/6)), the cloned files as this point still remains setting.xml(5/6). Thus, people on projectA & customerB can simply sync to the latest version.
Thanks.
You can use the Perforce client spec to map files from the depot into your workspaces, which should do almost exactly what you're looking for.
For example, your client spec for tool 1 would be something like:
//depot/projectA/tool1/... //workspace_for_tool1/...
//depot/central/config/setting.xml //workspace_for_tool1/config/setting.xml
And your client spec for tool 2 would be something like:
//depot/customerB/tool2/... //workspace_for_tool2/...
//depot/central/config/setting.xml //workspace_for_tool2/config/setting.xml
The main downside of this approach is that you need to make this change in every client spec, and you need some infrastructure dedicated to propagating client specs to new workspaces.
Consider a solution has 2 projects: ProjectA and ProjectB (both are MonoTouch apps) and ProjectBase. ProjectBase contains the whole application, but Main.cs file (with the entry point) is located in ProjectA and ProjectB (which reference ProjectBase). This way, running any of A/B projects will boot up the application from ProjectBase.
Now, I want to override something for ProjectA only (it might be XIB file, image or a .NET class). Is there any way I can setup the solution so that the code and resources, produced by ProjectBase, are merged with the ones from ProjectA/ProjectB and the latter wins?
I found (probably a quirky and kinda-undefined-behavior-driven way) of overriding XIBs: I just put a XIB into ProjectA and ProjectB, name it the same as it was named in ProjectBase and them exclude it from ProjectBase. Although MonoDevelop compiles all items, it seems that the startup project's XIBs get priority, so that I see ProjectA-specific XIBs when I launch ProjectA and ProjectB-specific XIBs when I launch ProjectB. However, I am not sure it is the way it should behave, plus, from what I can see from build log, ALL projects get built yielding resources at the end.
P.S. I'm sorry if this has been asked previously, but I was not able to find the similar question on SO.
I was once trying to do this for a bunch of apps. I would have thought build order would be ProjectBase and then ProjectA, and the content copy system would be the same... Guess this means we are wrong.
You could do a few things.
A) Build your own program to copy resources which are marked for content. Would not be very hard, just need to read the .csproj files. XML parsing is easy enough in .NET. Run this program on post build. Would just have to be careful when doing builds such as to zip or to the device as I am not sure how it handles post-build events.
B) [This is what I did instead] If I expect to also make ProjectC, ProjectD ... ProjectN I instead made a program to generate my program... (Programception).
What it does, has ProjectBase, and ProjectTempalte. You enter your new project name into this program, say, "MyNewProject" and it will create the correct folder structure, write the correct csproj files, and update SLN file. ProjectTemplate has various placeholders in .csproj files like {PLACEHOLDER} which Programception would just go through and find/replace with my project name. Image files (and in your case XIB) are then only kept within ProjectA (B..C..N) unless I do not expect to try and override them in which case they would stay in ProjectBase. This is a lot easier with a XIBless application I would assume. I never use XIB's anyway.
Hope that helps!
At work we are using Perforce and I wonder if it's possible to do submodules with it with versioning.
For example I have library A used by projects B and C.
I want to make it so that when I get revision of B I also get A in subfolder:
B
---=> A(v1)
Same goes for project C, but it would need newer version of library.
C
---=> A(v1.2)
I know this kind of thing is possible with Git, but could not find anything on it for Perforce.
Thanks,
Leonty
Perforce really handles this sort of thing with views and paths. These let you assemble the right set of files to put into a workspace (or branch or label). Since a Perforce repository can contain all of the components or modules for all your products, you just select which ones you want in a working data set. You don't need the submodule (or SVN external) concept to pull in data from another repository.
You can use template workspaces to make sure that developers get the right set of files to work on. You can be a little more rigorous and write some custom tools (possibly in the Perforce broker) to provide some structure.
The closest equivalent to using submodules is found in Perforce streams, where the paths define what goes into a stream. Stream paths are inherited by child streams. This isn't a direct equivalent though.
I use Tortoise SVN and I have one repository called "First". My SVN Location is C:\SVN.
Now, I created a new project in repository "Two".
The current structure is
C:\SVN
-> First
-> Second
I have few classes in First that I want to use in Second. Earlier, I just used to copy the files and modify it in second, but now since I am using SVN, I think it makes sense having just one copy of the class files and reusing them.
How can i check out the classes in First to be used in Second? And when I modify the classes, how can i update First??
Thanks.
You can reference a sub folder (or the entire repository) of repo First in repo Second using svn:externals.
This way when Second is checked out, it will also check out the files referenced from repo First.
Then, when you are using repo Second, and you modify the referenced class from First, you can commit them back. You will have to do this explicitly at the folder level used in the svn:externals reference, though. If you commit at the top-level of Second, it will not automatically commit changes to the sub-folder referencing First.
Either add projects that exist in First in Second, or add the files from First into your project/solution in Second. Note that this will assume a directory structure. For example: if First needs class A from Second, in the first solution, provide a link to file "..\First\A.class". Then it will be compiled into your Second project, but will really reference the file in the other repository, so updates to it will be made in the first repository.