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
Related
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.
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?
We just started using TFS and it works great. I have one question though, if we delete a folder it's not deleted on my local workspace. We are currently reorganizing a project and I wish to not have heaps of unused folders on my local drive.
Where can I configure this?
Thanks in advance.
In you have the Visual Studio Power Tools (http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f) you can use the command line tools tfpt to clean up all your workspaces.
In a shell window
change directory to your workspace root
type \tfpt.exe treeclean /recurse .
This will remove any file or folder not in source control.
Another solution, which also checks how well your project is put together, is to cut the whole folder and move it elsewhere, then perform a get across the project. This will allow you to check if the project will build or if there are some "magic" DLLs missing. Anything that is missing can be retrieved from the copy of the structure and added into source control.
I've been recently researching how I can manage source files in a project or multiple projects. I've read that Xcode has a built-in support for using svn, and will support git as well, both of which I found to be very useful.
The one thing I couldn't understand clearly is about Source Trees described in Xcode Project Management Guide. Here is my theory, but as I couldn't really verify this from anywhere (as far as I could tell), I would really like if someone could say what I'm missing, if any.
A Source Tree in Xcode preferences is more like a root of a source tree, which is a folder in my local file system.
I can use any files in any of my Xcode projects, even if the files are not in the project folders, if I can specify the files' location related to one of my source trees.
Now someone has the same project folder that is synchronized with mine. She has all files in the project folder, but the files referenced by a relative location to the source tree may exist out of the project folder.
But she has a source tree, with the same Setting Name to mine, (but absolutely in a different folder in her local file system), and if she has the file in the same relative location, then her Xcode can access the file without a problem.
So is this correct, and we use source trees because it enables us collaborating with files outside the project folder?
And even if the files outside the project folder is referenced by a relative path to the project folder itself (not to a source tree), if these files are all managed by SVN so they exist in the same relative location to the project folder in everyone's environments, then I wouldn't need source trees, right?
I never think I am an expert of Xcode, but it seems your question hasn't been answered for a while, so maybe it's worth commenting what I could say:
What you described is pretty much about it. Think is as an environmental variable of an operating system. Typically in a build system made by Autotools, for example, files are referenced by relative paths, such as $PROJECT_HOME/src/common/error.cpp. It doesn't matter where $PROJECT_HOME is in each user's local file system, as long as files are accessible by their relative paths to the user's $PROJECT_HOME directory.
And yes, you don't need to use source tree if the entire folder hierarchy used for a project is referenced by relative paths to the project home and somehow it is certain that everyone has the same files in the same location (for example, because a version control repository contains every files in a chunk as you said).
However, I think it's the best to keep all files in the project home folder, unless they are used across multiple projects, and therefore your version control repository only contains a single root directory (the project home) for your project. If there are files that are best to be shared by multiple projects, then I would have a separate repository for those files. In this case all of your coworkers must use the same protocol, say, having a source tree with the same setting name and put all project homes retrieved from your version control server directly under the source tree (so files outside a project home can be referenced in relation to the source tree for all programmers).
The most of my answer is kind of rephrasing what you already described, but that's how I use the source trees feature in Xcode myself. Maybe others can tell you more about it.