Our clearcase installation has multiple branches covering many years of development. I'm trying to search for a specific file (or part file name) and it could be on a branch that has never been merged back to the integration or MAIN branch.
Branch structure can be
main/branch1
and also
main/integration/branch2
Any thing i've seen on cleartool find needs a view but i've not be able to get a catch all config spec.
Any suggestions.
Thanks
The cleartool find command does not depend always on a view config spec:
find [ pname... ] –a/ll [ –vis/ible | –nvi/sible ]
You can also start with all objects in one or more VOBs, regardless of they are visible in a particular view
So you can use options -all and -nvis in order to search for all elements.
The view gives context for the command find to find the right vob (base on the pname argument.
The -nvis option will find elements, along with their branches and versions, that are not visible (do not have a standard path name) in the view.
Related
I'm working in a Windows dynamic view.
I am trying to create a tool shortcut using the ClearCase Menu Editor to automatically perform a 'mkelem' on all private files in my view.
I'm aware of 'cleartool lsprivate -other' to get a full path listing of all private files but I don't know how to feed that resulting list into the 'mkelem' command.
I'm also aware of the 'find' command and that at the end you can specific '-exec' to cause it to perform the additional action to be performed on the resulting list but once again I don't know what arguments to give to 'find' in order for it to only find view private files.
Can anyone help me with this?
Another approach I would consider/test is one I mentioned in "How can I use ClearCase to “add to source control …” recursively?", with clearfsimport.
I suspect clearfsimporting the view folder into the view itself should automatically add the private files, while keeping the existing files untouched. But, as commented, you would need to import in a new dynamic view (with same config spec) for that to work.
The problem with cleartool find is that it find versioned elements.
It can use %CLEARCASE_PN% or %CLEARCASE_XPN% as argument in its exec clause: that reference the pathname or extended pathname of already versioned element.
Well, it's complicated, because you would need to check out the parent directories before creating the elements.
Have you tried a command similar to this:
for /f "delims==" %x ('cleartool lsprivate -other') do #cleartool co -nc "%~px" & cleartool mkelem -mkpath -ci -c "autoadd" "%x" & cleartool ci -nc "%~px"
-mkpath makes any missing parts of the path to the elements at the same time the element is created. That should -- with appropriate massaging to make it work in a "cmd /c" or batch job do the basics... Of course, this also goves you 1 new version of the parent directory per new element.
If you're not averse to Perl, you can expand upon this by taking that list, making any needed directories, and them making the elements.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
how to ignore files in kiln/mercurial using tortoise hg “that are part of the repository”
I have a config file that I don’t wish to check in however I do wish to get updates whenever someone checks in a change to it.
In most systems I just need to uncheck the tick mark next to the config file at check-in time, however HG seems to make life a lot harder!
In parforce this even easier, I can just check the config file out in a different change list, how do I do the same in TortoiseHg?
In general, you don't. The usual way to handle this is not to put the config file in source control, but instead to put a template for it in source control. Something like config.sample. You can even tweak your run/build script to copy config.sample to config if config doesn't already exist.
There are plenty of other ways to try and get at this using mq or an alias like mycommit = commit -X config, but at its core a file is either tracked or it isn't and a file everyone has to change themselves shouldn't be.
If you uncheck the file from the file list before committing it won't go into the change set. This means it won't feature in a push (as these are per change set).
This is one feature of Tortoise that makes it useful over the command-line.
If you do a pull with an edited file, you will create multiple heads. You can merge these if you want the file to feature changes, but this might be a manual step.
Alternatively in the case of a config file it is useful to use the Patch Queue functionality of Mercurial. From the command-line this is possible thus (assuming it is changed in your working directory):
hg qnew "localConfig"
hg qrefresh
This creates a new patch queue item called "localConfigs", and puts the edited files (your config file) into the item. You can then:
hg qpop
To remove it from the patch queue (out of your change set path). Or:
hg qpush
To put it in your change set path. This is an easier way of managing file changes that you do regularly on top of keeping pace with the central repository: you pop your queue items out, pull and update, then push the queue items back on (handling any merge conflicts, though these are rare if your items are small). This way you avoid multiple heads.
https://www.mercurial-scm.org/wiki/MqExtension
We tend to use this mechanism in our office.
Note, pushing and popping acts like a stack collection; if "localConfigs" is on top of "moreLocalChanges" you will need both if you wish to push "localConfigs". My example assumes that the "localConfigs" patch is the only one in the queue. It is also disabled by default in Mercurial configuration, but comes bundled with it so you can enable it simply:
[extensions]
mq =
I need to label the contents of a view as seen at specific dates, and the only way I know of doing it is by using the -time version selector in the config specs. I set the time to the date I want, and then I apply the label on the view. Simple.
However, I was hoping if there is a way to do it pro-grammatically without changing the config specs. I was hoping that I could use the cleartool find in combination with -exec and mklabel. However, if I do this:
cleartool find . -cview -version "! created_since(some-date)"
It only pulls what was created before that date on the view, not necessarily what should be seen in the view if we were using the -time selector.
And if I use cleartool find with a -branch selector
cleartool find . -cview -version "! created_since(some-branch)"
it only selects that which was created before that date, on that branch only. It will not show what is also seen in the view on other branches via the config specs rules.
So, am I using cleartool find wrong? Or is it just impossible?
Is there a way, from the command line, to direct cleartool find to find exactly and precisely the elements that
would be seen by the active config rules
in a given directory
regardless of the branch or branches involved,
AS IF there was a -time directive in them?
Thanks.
To my knowledge, the query language isn't rich enough to include what the config spec time rule does.
A time-based selection rule is the best option.
What I generally do, in order to use the -time programmatically (since the find wouldn't work) is to:
use a dedicated dynamic view (quicker to update than a snapshot view)
write in a file the config spec I need
cleartool setcs -tag myView myFile # update the config spec of the dynamic view
(See setcs man page)
use the result of the updated content of the dynamic view.
The problem is pretty straightforward, I'm just not very well-versed in these tools (or CVSes in general).
Each branch of the project contains 4 folders:
branch-1
folder1
...
folder4
branch-2
folder1
...
folder4
...
folder4 is ginormous (~2GB), contains things I'm usually not interested in, and I'd rather not download it every single time -- it takes forever, and takes up space.
I see that the "Checkout from SVN" dialog has a Depth field, with options:
Fully recursive
Immediate children, including folders
Only file children
Only this item
None of these options is quite what I want. 1 and 2 will still download folder4, while 3 and 4 will omit everything.
Ideally, I'd be able to simply omit folder4 from the download initially, with the option to pull it down later. I don't mind seeing it as an incoming change (and simply ignoring it) during sync operations.
Any ideas? Am I missing something?
P.S. I tried to post this question in Super User, but the site is giving me real problems.
Yes, you can do this using Subclipse:
Check out using the "Immediate children" option. folder1, etc. will be empty.
Select the empty folders (except folder4) in the newly-checked out project.
Choose Team → Update to Version...
Set the depth to "Fully recursive".
Tick "Change working copy to specified depth".
Click OK.
Another way to do this involves the svn command line client:
Check out using the "Only this item" option. The top-level directory will be empty (folder1 etc. will be missing).
cd project-dir
svn up folder1 folder2 folder3
I was wondering what the best approach might be in moving source code, with history, from one Team Project to another Team Project. I am not concerned with work items, reporting, or SharePoint sites, as the system we are going to be restoring from did not use these functionalities. The reason for wanting to move to a different Team Project also is driven by the fact that the original implementation (being restored from a backup that was maintained by a third party) were using a third-party process template that we do not wish to use going forward. We want to start utilizing work item tracking and reporting after the migration is complete.
The TFS Integration Platform seems to be one likely scenario. It can be used to change the process template, according to the documentation. However, I was curious if the tf.exe move syntax might work? Something like:
tf.exe move $/ProjectA $/ProjectB
It is my understanding that this command operates much like a rename operation, whereas moving with the "Move" context menu item in Source Control Explorer is more like a delete and add operation. Also, would the tf.exe move path actually associate the code under the folders with the appropriate Team Project, assuming that $/ProjectA is the root source control folder for one project and $/ProjectB is the root source control folder for the other? The key is to be able to preserve the history, if possible.
Any advice or tips would be greatly appreciated!
Edit - Could branching to another project handle this scenario - much like Microsoft discusses in the Branching Guidance documentation? I think that this could be the answer, since the history would likely be preserved with the branch. However, I do not have access to a Team Foundation Server 2008 instance at the moment to test it.
Move and Rename are aliases. There is absolutely no difference, in any version of TFS, from the command line or the UI.
Both of them preserve history. At least in 2005/2008, you keep the same physical item in the VersionedItem table no matter how often or how drastically the name and/or parent path changes. There is actually no way to get a "fake" rename (delete + add) without a lot of manual work on your part.
However, while this versioning model is very pure in a theoretical sense, it has some practical gotchas. Because different items can occupy the same name at different points in time, TFS needs the full name + version to uniquely identify any inputs you send it. Normally you don't notice this restriction, but once have you renamed items in the system, if you say tf [doSomething] $/newname -version:oldversion then it will get confused and either throw an error or operate on an item you may not have intended. You have to be careful to pass valid combinations (newname+newversion or oldname+oldversion) to ensure commands behave the way you want.
TFS 2010 changes the story somewhat: it's a branch+delete under the covers, causing the itemID to change. Even so, everyday commands like Get and History are "faked" very well; old clients are about 95% compatible. The advantage is that when you have multiple renames in the system and path-based item lookups start to become ambiguous as alluded to above, the server will simply accept the name you specify and run with it. This improves overall system performance and eliminates several traps that unfamiliar users often fell into, at the cost of not being quite as flexible and not preserving history with 100% precision (eg when there are name collisions during a Merge of two branches).
Returning to the problem at hand...
It's not as simple as saying tf rename $/projectA $/projectB. Top level folders in the source control tree are reserved for the Team Project Creation Wizard; you can't run standard tf commands against them. What you need is a script like:
Get-TfsChildItem $/ProjectA |
select -Skip 1 | # skip the root dir
foreach {
tf rename $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB")
}
[of course, you can do it by hand if there aren't too many children under $/ProjectA]
As far as the gotchas I mentioned, I'll elaborate on one right now since looking up old history seems very important to you. Once you checkin the rename, tf history $/ProjectA/somefile.cs will NOT work. By default, tf commands assume version = "latest." Any of these alternatives will the full history you want:
tf history $/ProjectA/somefile.cs;1234 where changeset 1234 was before the move
tf history $/ProjectB/somefile.cs;5678 where changeset 5678 was after the move. Or you could just omit the version.
A final alternative for completeness & debugging purposes:
tf history $/ProjectA/somefile.cs -slotmode. You will only see the changes that happened prior to the move; however you'll also see the history of any other items that may have lived in the $/ProjectA/somefile.cs "slot" prior to or subsequent to the item you moved underneath B.
(In TFS 2010, "slot mode" is the default behavior; there's an -ItemMode option to request that your lookup be traced across history like it was 2008 rather than path-based.)
EDIT - no, branching is not a great alternative. While branching does leave enough metadata in the system to trace the full history to & from ProjectB, it's not terribly user friendly in 2008. Plan to spend a lot of time learning the tf merges command (no UI equivalent). 2010 dramatically improves your ability to visualize changes across multiple branches, but it's still not the clean unified experience you'd get from a Rename.
Richard's answer above is well written and explains the situation well. I did have a couple more practical gotcha to add, however.
In TFS2010, the default behavior makes it seem like moving a file causes you to lose all history from before the move. The command my users are likely to use (and the one used, it seems, by the VS2010 GUI) is:
tf history $/ProjectB/somefile.cs
My users intend to get all the history of somefile.cs, both before and after the move. They want "the history of the code that is currently stored in $/ProjectB/somefile.cs", regardless of the filename at any point in time. Maybe other people see it differently.
The first gotcha is that the GUI that appears for me in VS2010 using TFS2010 initally shows only the history since the move. The least-recent item in the list is the rename operation. It can be expanded with a subtle little drop-down arrow. Underneath is the history from the previous location. If you don't know to look for this, it can look like your history is gone.
The second gotcha is that if you later delete ProjectA (because you've finished the migration to ProjectB, say), the history really is gone. Expanding the drop-down in the history for $/ProjectB/somefile.cs doesn't produce the older history.
Another option (and I think easier) is to import to Git then export back to TFS using the Git-TF command line tools.
Install Git-TF from binary, Choclatey or source code.
Clone a TFS folder:
git tf clone https://myAcc.visualstudio.com/mycollection $/TeamProjectA/Main --deep
Disassociate the Git Repo from the TFS server by deleting the .Git/tf folder and the .Git/git-tf file.
Configure the new Git Repo to connect to an empty TFS folder.
git tf configure https://myAcc.visualstudio.com/mycollection $/TeamProjectB/Main --deep
Don't forget the --deep
git tf pull
You should get a message at this point "git-tf: this is a newly configured repository. There is nothing to fetch from tfs."
git commit -a -m "merge commit"
git tf checkin --deep
Regarding the original command above:-
Get-TfsChildItem $/ProjectA |
select -Skip 1 | # skip the root dir
foreach {
tf rename $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB")
}
Both the source and target names need to be surrounded by quotes in case there are any spaces in the full pathfilename. I found it difficult to do this on $_.ServerItem as surrounding it with escaped " returns that whole child object and not just the .serverItem string. Or if I did manage to get the string, I got unwanted carriage returns such as
"
$proj/folder/file
"
Eventually I got the command to work with the following, but I found that the history still doesn't get transferred, which was the whole point! So I believe this command is the direct equivalent of just using a right mouse click in source explorer and selecting rename (or move).
$tfsServerString = "http://machine:8080/tfs/DefaultCollection"
$tfs = Get-TfsServer $tfsServerString
Get-TfsChildItem -server $tfs "$/Dest Project/MyTestProject" | select -Skip 1 | foreach { $sourceName = $_.serveritem; $targetName = $_.serveritem.replace("$/Dest Project/MyTestProject/", "$/Dest Project/Source/StoreControllers/dSprint/dSprint2/") ; ./tf rename `"$sourceName`" `"$targetName`" /login:myUser }
Also note, it requires use of the backtick ` to escape "