I am running code review tools on a large application. The code is all held in a ClearCase team view, but information on the Maven build is held in another. The developers get a view which includes the code and the Maven build repository, but that is not possible for test teams here. I have a view which lets me see the code and another view which gives me access to the Maven repository.
My problem is I can't seem to find a way to have both views active at once.
To run my test tools I use cleartool setview -exec "test scripts etc" mycodeview
Is there a way to run my review tools while also having access to mymavenview?
I confirm that for dynamic view, you cannot use cleartool setview for several views.
setview is only a way to mount the vobs directory within your dynamic view to /vobs.
I would rather use snapshot views, update their content in a custom path, and through symlink (not managed by ClearCase), make sure I see the relevant content of one view from the other.
Notes:
a cleartool symlinks isn't useful here, since one view don't reflect the full content you need.
dynamic views could be used, but I find them much slower in those case that snapshot views.
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/
Like most people we use third party libraries. Many have source which we keep in our VCS.
Currently if these libraries are updated, we need to pull the source manually and rebuild the binaries.
I am trying to find a way to instead reference them from the various solutions that use them, so that they will be automatically pulled from source control when you pull the dependant project, and automatically built if they are out of date. It would also be nice to be able to debug into them with the provided source.
The first problem I am having is that the libraries are not in the same solution root as the dependant projects. eg.
\Libraries
\External
\Lib1
Lib1.sln
\Products
\Product1
Product1.sln
Attempting to add Lib1.csproj to my Product1 solution gives me the warning:
The project that you are attempting to add to source control may cause
other source control users to have difficulty opening this solution or
getting newer versions of it. To avoid this problem, add the project
from a location below the binding root (C:\depot\Products\Products1)
of the other source controlled projects in the solution.
If I ignore this then I can set up build dependencies properly, but it still doesn't allow pulling the entire source tree in one go.
I was wondering how other people have third party libraries set up, particularly when there is source code. (We are using Perforce but I guess the question is relevant for any VCS)
One way to solve this in perforce is to put all modules / 3rdparty-software that are about to be reused to a separate location (depot), for examples "//shared" or similar.
Products (trees in your SCMS / perforce) can "link" the required modules by mapping them into the workspace. In perforce you can do that via clientviews.
If you have many people working on many products you'll need a easy mechanism to set up a personal workspace for a product properly (without requiring the developers to setup their clientview manually).
One possibility to achieve that is a small self-written tool/script that sets up a workspace and prepares the personal clientview based on a template that is located in the product-root and that defines what modules from the "//shared" depot need to be mapped to which location in the client workspace.
We are using this practice since years and it works fine. The danger is that the clientviews can get very complex.
We have a huge codebase with around 27000 files in ClearCase UCM. Our build process is as follows:
Copy files from the dynamic view of the stream to the local machine(say directory D:\ABC)
Start compilation
The next time we compile we clean up D:\ABC and repeat the above process. The copying takes around 50 minutes.
The reasons we prefer dynamic views over snapshot views are:
We can always be sure that we are using the latest code
We generate a lot of code and modify a few existing ones during compilation. This may turn snapshot views dirty.
We are saved from the trouble of cleaning up the snapshot views, rebasing it etc...
The troubles with snapshot views are:
We need to clean-up the code we generated for the last build(these are shown as view-private)
We need to undo hijack(we remove read-only for some files as they have to be modified at compile-time)
We have to clean up the output directories and files therein, created by Visual Studio during compilation
We need to rebase the snapshot view every time we intend to compile
We do not trust the snapshot view's cleanliness
My questions:
Are we doing the right thing by copying files from the dynamic views?
I wanted to know if there is some way we can use snapshot views and still be sure about it being clean?
Is there any other option or best practices that we can adopt to improve our process?
Any help would be appreciated.
1/ No:
Copying from a dynamic view is waaay longer than using directly a snapshot view that you would simply update (to catch the latest code)
Plus, during the copy, a file can be updated (new version checked in), and would then be copied by your process (because the dynamic view would... dynamically pick up said new version). In short: you don't know what you are copying.
an update of a snapshot view is an incremental process.
Copying a dynamic view is not (it will copy everything instead of downloading only the delta)
2/ You would update -overwrite to make sure any hijacked file is removed
3/ Using a Baseline is safer, in order to get a fixed point in time of the code base
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 use Clearcase at my work and I have several snapshot views setup (on Windows XP). The views themselves seem to work great, however whenever I try to compare any versions of any elements from my snapshot view, I have problems with my diff tool (currently Beyond Compare). Specifically, if I'm comparing with previous, I see the current version great, but the previous version never shows up in the diff tool.
I've looked into the problem a bit and looking at the command line that is getting passed into the diff tool, CC is passing in a bad path to the file. The path to the file that is not working looks something like this:
//server/path/to/viewstorage.vws/....
The problem appears to be in the //server used to access the SMB share where the file is found.
Where is CC getting this bad path from? Is this something specific to how my snapshot view is setup (this worked for a long time and still works on some of my co-worker's machines)? Is there any way to change this path to the typical \\server that Windows expects?
Update:
Ok, so my original question was written from home, and wasn't entirely accurate. The actual path is more like this:
//server/path/to/vobstorage.vbs\....
To answer #koslorr question, the global path for the view is correct (the view is actually stored on a public share on my machine), however doing the similar command for the vob (cleartool lsvob -l /my-working-vob) does show that the global path for the VOB is incorrect. Can this be updated in a similar way to the view tag? Is this something my CC admin is going to need to do?
Check your view Global Path with
cleartool lsview -l <VIEW TAG>
Is the Global Path in the correct \server.... form?
If it is not, then you can use
cleartool mktag -view <VIEW TAG> -replace...
to change it to the correct form.
cleartool man mktag should tell you more in details.
What a cleartool diff -pred myFile gives you when executed in your snapshot view path?
cd c:\path\to\my\snapshotView\myVob\path_to_myFile
cleartool diff -pred myFile
If the global path is incorrect, it can be because of:
an incorrect mktag (cleartool man mktag), as kolslorr mentions in his answer. Don't forget to specify the host of the view storage as well as its global path (see "Renaming a ClearCase VOB or View")
an incorrect region (see your ClearCase control panel): the view might be correctly defined in another region