UPDATE: I missed a layer in the directory structure (the laravel parent folder, specifically). I'm quite embarassed...
I have a Mercurial repository tracking a Laravel project I've built under
IIS 6, with the following directory structure:
inetpub
|--laravel
|--app
|--bootstrap
|--vendor
|--wwwroot
|--Project
|--OtherScript (set to ignore in .hgignore)
I now want to begin work on a second project, and have modified the directory structure accordingly:
inetpub
|--laravel
|--app
|--app2
|--bootstrap
|--bootstrap2
|--vendor
|--wwwroot
|--Project
|--Project2
|--OtherScript (set to ignore in .hgignore)
I've added the "2" folders to the .hgignore for the original repository, but I'm having trouble working out how to set up a separate repository that ignores the original project folders, and will just track the 2s. I thought I could just create a new repository covering inetpub that uses a different .hgignore file, but when I create the repository it automatically references the .hgignore file established for the first repository. I'm presumably missing something, but I'm not sure what. How can I make this work? The project is just starting, so restructuring is entirely viable if that's necessary.
Two repositories residing in the same directory does not work.
There are several options which might suit your needs, though:
a) Use a parent directory in which you organize your projects in sub-directories. This is usually the recommended the standard approach with mercurial; each of the sub-direcoties becomes an independent repository. The parent directory would not contain much, but can be made a separate repository as well, if desired.
b) Use branches for different projects. Switching between projects then requires switching branches in your project.
c) You can extend option (a) and consider using sub-repositories or guest repositories. They come with some rough edges, thus their use will need careful consideration. You can also start with option (a) and convert it to option (c) at any later time. See Subrepository and also the links in the 'Alternatives' section.
As an aid to others fumbling their way to a better understanding of doing this with Sourcetree, here's a quick overview of what I've done based on planetmaker's advice.
Used the "Clone/New" option to created individual new repositories from the app, bootstrap and Project folders (I've determined that there's no point in tracking vendor).
Committed the contents of each of those repositories.
Created a new Project_Repository folder outside of inetpub
Created a new Repository from the Project_Repository folder
With the Project_Repository tab open, selected "Add Subdirectory" from the Repository menu, and selected the app directory.
Repeat 4. for bootstrap and Project
After doing that, I have a current copy of the content of all 3 directories in the Project_Repository folder, along with the appropriate .hg files. I'm optimistic that this will work well for Project2 as well.
Related
I've got a solution in which I'm trying to create a 2nd executable. These two executable share most of the same files, but have a few different ones including resources and application icon, etc.
I created the 2nd project, and added the items as links.:
Right-click "Add existing item",
Browse to it,
Click the "Add" drop-down and select "Add as link".
Adding as links means that it just references the other file in the other folder and does not copy it.
Now, when I tried to commit my project VisualSVN / SVN tried to do an SVN add on those files in the logical path they belong to resulting in lots of errors that the file was not found. It caused the entire commit to fail and was a major pain in the ass.
Is there a good way I can add links to files without side-effects? All the files I'm trying to link to are already in the same repo.
Update
Maybe I should add more information about what I'm trying to accomplish because I'm open to any suggestion which helps me accomplish it.
I have a project structure something like this... Or I want it to be like this...
MyProject
/Common
BusinessDataObjects (svn:external)
ControlsLibrary (svn:external)
OtherCommmonLib1 (svn:external)
OtherCommonLib2 (svn:external)
/Modules
Module1
Module2
Module3
...
Application1
Application2 (shares all App1's files, except different .resx, icon, name, other minor differences)
SetupProject1 (includes app1 and certain module dlls)
SetupProject2 (includes app2 and certain module dlls)
The application is basically an empty shell (using Prism) which loads the modules installed in a /modules folder. I want both applications to be almost identical, but I want them to have different names and a different icon. I thought I could accomplish this by adding the files from the first project to the second as a link, and simply swapping a resource file which included the strings for the application window title, About dialog, etc. But then VisualSVN or whatever tried to SVN Add those items which I wasn't expecting.
I need to be able to develop the modules and the application's shell project. They are not stable in any way yet. I just want them to near copies of each other but with minor naming differences. I figured with two application projects, I could have two setup projects that included the output from each application and whichever modules are supposed to be included in that version of the software program.
I was trying to make this as foolproof as possible, and I'd like to avoid having to update external references to the same project. (I'm a bit confused about that as well, would I svn:external to the same repo?) That doesn't sound good, but this was my main idea on how to create two almost identical apps. I'm not sure how else I'll do it if I can't get my version control software to behave.
I had suggested oringally we only have one version of the software and have certain modules be upgrades, but there are some good reasons they can't really do that.
When you add a file to a Visual Studio project with "Add as link" it's expected that the file is not copied to the project's folder.
VisualSVN considers status of items in your working copy, even files which are not included in the current solution. However a linked file does not exist in a working copy, thus can't be tracked. It's out of version-control.
Since the files you attempt to link are already version-controlled (i.e. they exist in the SVN repository) it makes sense to use Externals Definitions (svn:externals property) to link them.
Also see TortoiseSVN Manual; it's description of svn:externals is really good.
You don't mention your environment. However, you mention you have a Solution. I'm assuming it's VisualStudio you're using.
Have you tried AnkhSVN which is a Source Control Provider for Subversion for VisualStudio? AnknSVN integrates into VisualStudio much like Microsoft's native version control systems of Visual SourceSafe and TeamFoundation. I believe you can use AnknSVN to do the linking you want since these links are really internal VisualStudio structures and not actual symbolic or hard links like you find in a Unix system.
I usually avoid links (I believe they're called Junctions on Windows) because they simply don't work across operating systems. Instead, you can use one of the following methods:
Use your build system to copy the files, or create the required links rather than your version control system.
Use svn:externals to do the linking. Careful with this because svn:externals are pointers to a Subversion URL.
For example, if I setup http://foo.com/svn/trunk/proj1 to have a svn:externals link to the head of http://foo.com/svn/trunk/proj2, and I create a tag for Project 1 by copying http://foo.com/svn/trunk/proj1 to http://foo.com/svn/tags/REL-1.2/proj1, that project is still pointing to the head of the trunk of proj2. Changes in Project 2 will change what I thought was a stable tag. Always point your svn:external to a stable revision.
I have no experience with VisualSVN, we use Ankhsvn which does not have that problem.
http://ankhsvn.open.collab.net/
I have a project with a sizable codebase. Associated with that codebase is a large amount of documenation that needs to maintained at the same version as the source code and which also needs to be easily accessible from within the codebase. However when our build machine builds the codebase I do not want the length of our build process extended by having the build machine checking out hundreds of megabytes of development documentation which is not needed for the build.
If this was on Unix I could simply have a 'docs' directory at the peer level of the codebase's 'source' directory. Then individual projects in the source tree could reference documentation in the docs tree using symlinks, and when the build machine does a build it would just check out the source directory and so not waste time checking out the unneeded docs directory.
However using SVN on Windows I don't see any way to set this up in a sensible way at all since SVN doesn't support symbolic links on Windows, even though Windows has them.
The only workaround I've come up with so far is to create batch files in the source tree which use cmd.exe and a relative file reference to open the documentation files in the docs tree. It works, but for some reason I can't quite put my finger on it leaves a nasty taste in the mouth.
Can anyone think of a better way of achieving this?
After some research I think I have a solution using the externals property.
Firstly using the svn:external property to reference a directory in the same repository. Set this on trunk/Proj1 to create Proj1/Docs referencing the contents of DocsDir/Proj1Docs
../DocsDir/Proj1Docs Docs
This creates a disconnected child working copy inside Proj1/Docs which references /DocsDir/Proj1Docs. Proj1/docs must not previously exist as part of the outer working copy (which makes sense since that would make it part of two working copies at once). If you edit the contents of Proj1/Docs then executing svn status inside the 'parent' working copy will list the changes to the child working copy, but you have to commit the changes to the child copy separately. Which is not a big deal.
Secondly using the svn:external property to reference to a file in the same repository. Set this on trunk/Proj1 to create Proj1/Readme.txt which references DocsDir/Readme.txt.
../DocsDir/Readme.txt Readme.txt
In the case of a file reference the directory in which the referenced file is imported must already be part of the owning working copy. In this case no child working copy is created and if you edit the file it is commited seamlessly as part of the owning working copy.
In both cases the build machine can execute
svn checkout --ignore-externals <path>
to checkout our codebase without all the bulky documentation.
Can anyone see a problem with this strategy?
I am an inexperienced Mercurial user. I am using VS2010 with Mercurial. I had everything working nicely against a single repository, which contained a solution file and two projects nested within the 'parent' folder. Whenever I changed a file then the commit process would detect the change etc, etc.
Then I added a third project. I added this project in a new folder, where the new folder was a peer of the top-level folder containing the original solution file (with original 2 projects nested within). Although the third project has been added to the solution file, it is not being recognised by Mercurial as 'belonging' to the solution in terms of source control. Indeed, it is not showing as being under source control at all.
How do I add the third project to the same repository, even though it sits 'outside' the original folder which maps to the original Mercurial repository?
Thanks very much.
No, you cannot add anything that is not under the repository root. hg add will abort with X not under root message. Move your files into the repository, or move the repository so that all of your files are under the root (note that this will generate a lot of file moves, and you really shouldn't do that).
I found the best way to manage multiple folders in one repo by just creating a symlink (mklink in windows). I usually work in Visual Studio, so I typically have a code library and a website directory, but they are not in the same parent folder.
You can create a symlink on windows like so:
mklink /J "Target Path" "Source Path"
So I would have a structure like so:
project root
- Code Library
- Solution File
- Web Folder (symlink from locally-hosted website folder)
You should use a different repository for each project. This is because when you do a commit in hg, the commit is for the entire hierarchy, not just the directory (and below) that you are in. For more details have a look at the One last big conceptual difference section of http://hginit.com/00.html
I have a TFS structure that looks something like this:
$
-MainSoftwareBranch
-Dev
-Main
-Enterprise
-Project1
-Test
-TeamProjectA
-Main
-Enterprise
-Project1
-TeamProjectB
-Main
-Enterprise
-Project1
The end goal of this is that MainSoftwareBranch (MSB) contains all of the software that our company develops. When you need a piece of the software, you branch it in to your project branch and add a project reference wherever necessary.
At some time in the past, somebody who was not very familiar with our branching strategy branched Project1 directly from TeamProjectB to TeamProjectA instead of from MSB. I have tried to fix this and removed the project reference to $/TeamProjectB/Main/Enterprise/Project1 from where it was referenced in TeamProjectA. I branched Project1 from $/MSB/Main/Enterprise/Project1 and tried to add the project to the solution using "Add Existing Project..." and browsing to the local path where the csproj file is located. The project that gets loaded is the one from $/TeamProjectB though. I've removed the source control bindings, both within TFS and manually in the csproj and sln files, but nothing changes. It's always "redirecting" my request to open the correct csproj file to the old one that is not valid.
Does anybody have any insight in to what could be causing this bizarre behavior?
A couple of things to check... but before you do any TFS/project structure modifications, I recommend checking in all current changes (for all teams), doing a get-latest to retrieve all of these changes, and making a backup of your entire local workspace folder.
One point I need clarified to fully answer you... what sub-folders are being branched? I.E. would you normally branch MSB/Main to TeamProjectA/Main, or would you branch individual projects, e.g. MSB/Main/Enterprise/Project1, Project2, etc.?
First: Check your workspace mappings... in Visual Studio, open the Source Control Explorer. There is a workspace drop-down at the top of the window... pick "Manage Workspaces..." and edit your main workspace.
Ideally there is only one working folder, mapping the root of your TFS project ('$' in your case) to a root local working folder. If you have more than one working folder, make sure that the second one(s) are not subfolders of the root. I.E. you shouldn't have a separate folder for $/TeamProjectA/Main/Enterprise/Project1. If you do, delete it and do a get-latest from the root.
This is my first guess, because if TeamProjectB/Project1 is mapped to a TeamProjectA folder, it doesn't matter how many times you change the references, you will always be loading Team B's project.
Second: You only do a branch one time. Everything after that is merging, and you can only merge between immediate parent and children (unless you jump through hoops to manually mess with merging... a shootable offense in 9 countries).
What that means is that so long as Project1 was branched from TeamProjectB, you will always be tied to TeamProjectB... You can fix the references in TFS for each Team and for the project, but when you merge TeamProjectA back to MSB, Project1 will not merge to MSB with everything else.
It's not clear in my mind what WOULD happen... either that project just doesn't merge with anything, or it merges back to TeamProjectB's folder. I highly doubt the latter is the case, but the former doesn't make much sense, either... I'd almost expect TFS to short-circuit in some way.
I'm guessing (complete WAG) that since you were able to branch Project1 from TPB to TPA that you're not branching /Main or /Main/Enterprise... I hope the answer is that TFS won't allow you to branch to a sub-folder of another branch.
To Fix This
Merge Project1 back to TPB. Check in.
Merge TPB/Project1 back to MSB. Check in.
Select TPA/Project1. Go to File -> Source Control -> Branching and Merging -> Reparent. Pick MSB's Project 1 as the new parent. If your branches are done from /Main or /Main/Enterprise, you will have to reparent from whatever the branch root is.
(Note that if TPB/Project1 was not rooted from MSB, this will not be an option... Go to plan 'B')
Not sure if you can/need to check those changes in... do a check-in on both TPA and MSB to be safe
Plan 'B': If that doesn't work, you will have to delete TPA/Project1 and re-branch from MSB. Make sure everything is merged the whole way back to MSB (and checked in) before doing this.
TFS may complain about re-branching to a pre-existing directory (because it keeps the delete history of TPA/Project1)... I don't think it will, but if it does, you will have to use the command line tool to permanently remove TPA/Project1. Command is tf destroy... make sure you run it from the local TPA/Project1 folder, or tf may not be able to resolve the tfs server/path.
HTH!
James
Project references have nothing to do with TFS. They are references relative to your local disk.
Now, if your projects happen to be located in a TFS workspace on your local disk, then you will have references relative to the workspace.
Look inside the individual .csproj or .vbproj files to see what the references are to. I suspect you'll find that you have relative references like ../../../../SomeProject.csproj, where the relative path goes up out of your workspace and then back down.
I've got several projects:
P:\Projects\Common
P:\Projects\App1
I originally added each of the folders (and their sub folders) to CVS (using Tortoise).
Now I want to be able to just right clock Projects\ and "Commit" everytime I save anything in those folders.
However, it seems that \Project is separate from \Common which is also seperate from \App1
So if a file shows it' needs a checkin in \Common and I do a Commit on P:\Projects, it shows "no changes"
Is there any way to force all the subtending folders to commit?
Or is there a way to merge all of them? (Or even start all over with a new repository so that all of P:\projects are in the same "project" so that I can just do one checkin for all of them?
You could either make a new CVS module that is a parent to all of your other directories or look into alias modules.
I have used alias modules to bring together multiple components into a single checkout (and therefore check-in) but you do need read/write access to the CVSROOT module to set it up.
This walkthrough of someone setting up something similar may be useful to you.