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?
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 am currently developping an application in MS VS2010 that's based on a client-server architecture with one project for each part in VS. Until recently, they both had their own repositories in Hg, but I decided to move them together as there are quite a few files that are now shared.
I have been using hard links to make sure that the changes on one file are propagated to the same file in the other folder/project. However, if you clone the repository or check out from the online repository, the hard links are broken.
I have read up as much as I could on both soft & hard links with Hg, and neither of them seems to be a good, portable solution at this point. What method of sharing the files between the two projects would you recommend, keeping in mind that I would ideally like a clean structure that is also reflected in VS?
Best regards,
Max.
You could use Mercurial's sub-repository feature to put your shared files in an external repository and share it in the places you need. There's also the guest repository extension, which is relatively newer and lighter-weight than a sub-repo.
Instead of solving it in version control, however, I would re-arrange your Visual Studio project so that your shared code compiles to an assembly that your client and server assemblies use and depend on. Share code at the assembly level, not the code level.
If you really must keep your existing structure, I would use NTFS junctions (similar to UNIX-style soft links) to junction in the shared code where it needs to go. You would then add these junctions to your repository's ignore list (in .hgignore). Create a PowerShell script that you and other developers can run that will initialize your repository with the right junctions.
I could use some advice.
I'm in the process of adopting subversion, and I'm trying to put some existing Visual Studio 2010 projects into a repository. I have the current version of AhnkSvn.
The projects I have are organised as;
VS2010_projects\Project_A
VS2010_projects\Project_B
VS2010_projects\Project_C
VS2010_projects\Common_code
Where Project_A, Project_B and Project_C may all refer to one or more files in "Common_Code"
In visual studio, these files will have been added using "add as link".
There is no actual project in "Common_code" just a collection of useful code files, which we're likely to re-use in different projects.
(If we have a module or class which is re-used in various projects, then we often keep a single master copy in 'common-code', and link to it.)
Visual Studio has no problem with this.
When I add any of the actual projects to subversion, all of their own files are added just fine, but the linked files are ignored.
(And as a consequence, if I then get a working copy of those files, then it's just the project files which get handled, I won't get a copy of the linked files.)
If I right click on any of the linked files, I the only subversion options I get are to refresh their status or to select the working folder.
I was wondering what the correct way to handle this situation was ?
Any advice would be much appreciated
Thanks !
Robert
if I understand your question correctly then I think SVN is acting in the desired way. A linked file is merely a reference to another file. That reference exists only in the .csproj file which is checked in. It would not make sense to have two copies of the same file in source control, and it could lead to versioning issues. The first time you checkout your repository doing a build on your projects should copy the files from Common_code to the places that they're linked.
As an aside we've had alot of random issues with .csproj linked files and SVN, and so try to avoid linked files where possible. A better way to re-use files across projects is obviously just to embed them in a library and then reference that library. This should work fine with the exception of certain files like Javascript/CSS.
Also you may want to check out SVN externals, a workmate mentioned this can be used to share common libraries between multiple projects, although as a disclaimer I haven't tried this myself and can't comment on the merits or drawbacks of the approach.
Thanks for the advice, I actually did something similar to your suggestion.
I didn't want to make a full blown library, but I did make up a dummy project, and put my shared files into that.
Then I added the dummy project to the repository.
AhnkSvn now seems to be satisfied that the linked files are under subversion control, and seems to handle them just fine.
(I haven't added any reference to the dummy project to my existing projects - they just use the linked files as before - but now AhnkSvn shows me their status, and allows me to get the latest version, and commit changes.)
I can see the case for having a proper library - but that would have meant modifying a large body of existing projects. This approach lets me get up and running with Subversion without requiring those changes first.
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.
As I create more applications, my /code/shared/* increases.
this creates a problem: zipping and sending a project is no longer trivial. it looks like my options are:
in Xcode set shared files to use absolute path. Then every time I zip and send, I must also zip and send /code/shared/* and give instructions, and hope the recipient doesn't have anything already at that location.
this is really not practical; it makes the zip file too big
maintain a separate copy of my library files for each project
this is not really acceptable as a modification/improvements would have to be implemented everywhere separately. this makes maintenance unreasonably cumbersome.
some utility to go through every file in the Xcode project, figure out the lowest common folder, and create a zipped file structure that only contains the necessary files, but in their correct relative folder locations, so that the code will still build
(3) is what I'm looking for, but I have a feeling it doesn't as yet exist.
Anyone?
You should rethink your current process. The workflow you're describing in (3) is not normal. This all sounds very complicated and all basically handled with relative ease if you were using source control. (3) just doesn't exist and likely never will.
A properly configured SCM will allow you to manage multiple versions of multiple libraries (packages) and allow you to share projects (in branches) without ever requiring zipping up anything.