I've created a new folder (with files and sub-folders) in a workspace. I then promoted them all into a parent stream (and even to the grandparent one). However I cannot see them in another workspace stemming from that parent stream. It does not appear in Exclude/Include mode either.
What am I doing wrong?
Thanks,
Michael
Michael - you'll need to 'update' the other workspace. That (older) workspace only has visibility to the transactional state of its backing streams as of its last update... part of the TimeSafe architecture.
HTH _ dave
Michael, it may require some debugging through support, but there's no logical reason for that content to not appear once you update. It's possible the workspace is out of sync. From a command-line, please perform the following in the P&C workspace:
accurev stat -m (This checks for modified files in progress. If any exist, Keep them)
accurev update -9 (This forces the workspace to update to the current transactional level)
accurev pop -O -R . (This replaces the content of the workspace)
At this point, after the update -9, you should be able to turn on Include/Exclude and see the new content. If not, I'd suggest you log a Support case with AccuRev.
Regards,
~James
Related
I changed a lot of files in one of my ASP.NET Solutions and checked-in. Afterwards I realized I wanted to role back to my original files. I am aware I could have just went to Source Control explorer and rolled back the changeset but I went about it wrong. Since I took a backup of my entire project directory prior to doing this I figured it would be easy to simply just replace the directory with my backed up files.
After replacing the entire directory with the backup and When I open the solution I get the following message:
One or more source control bindings for this solution are not valid
and are listed below. Source control bindings can be modified by
selecting File, Source Control, Advanced, Change Source Control from
the main menu.
Then all of the .csproj files are listed below.
I followed the instructions that I saw on many websites saying unbind then rebind and it is not doing anything for me.
My first question is why did this happen if it is the same exact set of files that have all of the source control bindings.
My second question is how can I go about getting this backed up solution in source control again?
I expect it to be in source control showing me the pending changes so that when I check-in the latest version in source control will be my replacement version.
Unlike windows file system, you shouldn't simply copy and past the backup files. It will definitely cause source control binding conflicts as you encountered.
You should use rollback entire changeset feature. This will influence your source control in TFS. If you roll back a file to an earlier version, tfs will eliminating the effect of all changesets that occurred after that version. More details please take a look at this tutorial: Roll back changesets
Since you just need to go back the old version files, you could now roll back your changesets to the one you back up the entire project. Check in the roll back operation.
Another way is as below if unbind/re-bind the project is not work:
Unbind project in Change Source Control
Unload project in Solution Explorer
Reload project in Solution Explorer
Note: If you use above option, the TFS consider all project files as newly added files to the solution.
In our company, we're using ClearCase on Windows. Since dynamic views have proven VERY slow for us, we're primarily using snapshot views.
Today we found a really nasty problem regarding symbolic links in snapshot views on Windows.
As we all know, in a snapshot view (at least on Windows) ClearCase models symlinks not via actual file system symlinks but simply as copies. That is, if your original file is /myVOB/dir/fileA.txt and /myVOB/anotherDir/fileA.txt is a symbolic link to the former, in a snapshot view the former and the latter are simply identical copies of each other. The problem now is that if you checkout and edit the original file (maybe as part of a merge operation), the change is not mirrored in any of the symlinks pointing to that file. Even a view update won't change that ... it will after you've checked-in your changes, but not before, and this is a huge problem because we're using an automated, gated check-in that automatically merges changes from a source branch into a snapshot view, runs the build and any subsequent tests and only proceeds to check-in the changes if the build and all tests were successful.
Due to the above mentioned issue, we've found that it is possible for a gated check-in (i.e. the build and tests) to succeed even though the merged changes should cause it to fail. All it takes for that to happen is the build referencing a changed file or directory not via its true, original path but via a symlink, which will cause it to see the original, unchanged rather than the changed, merged version.
Does anyone have an idea how to work around this problem other than "Just use dynamic views"?
When considering symbolic link on Windows in ClearCase snapshot views, there does not seem to be any magic solution.
One workaround would be to have a list of those symbolic link (assuming that list is relatively static and does not change often) and, before each build/test, copy the original file (if a cleartool diff shows any difference) to those symbolic links referencing it.
antred adds in the comments:
Here's our final solution:
Perform the merge in a DYNAMIC view, do NOT check in.
Use robocopy to sync the view to a storage location on a hard drive (relatively fast), then run the build / tests from there.
If it succeeds, check-in changes in dynamic view; else undo checkouts. :)
I am try to deliver code from my dev stream to QA stream and the delivery is erroring out(unable to merge) one particular file. When I look at the file from Clearcase Explorer, it is showing the file state as 'Not Loaded, Checked out but removed" as shown in the screen shot below:
When I try to do a UndoCheckout from Find Checkouts I am getting the below error:
Error undoing the check out for 'Z:\buildSupport\...'
Not an object in a vob: 'Z:\buildSupport\...'
Pathname provided did not resolve to a version object.
Not an object in a vob: 'Z:\buildSupport\...'
From Command Line I am getting below error when tried to get status of the file
cleartool ls AuditAssignment.jsp
cleartool: Error: Pathname is not within a VOB: "AuditAssignment.jsp"
Please help to solve this issue. I am in a UCM environment.
Z:\ suggests a snapshot view which has been mapped to a letter drive through subst.
Depending on your exact OS, it could be a case of path length limit that I mention in "not able to build in clearcase snapshot csproject".
But you also have other causes, like this IBM technote suggests:
When the link is created with a relative path using the wrong case, even though the link is created, the files within that linked directory can only be viewed through the Windows command line (cmd). However, they are treated as if they are not in version control anymore.
Even if symlink is not involved here, check if there is a case issue (with the same name versioned but with a different case, like the status picture seems to indicate)
Windows would not be able to show, especially in a snapshot (UCM or not) view, two files with the same name and different cases.
It is important when the merge is done that a file 'AuditAssignment.jsp' is present on both sides with the same case.
Once the case is identical on both side, then a merge can be attempted.
There are many possible reasons.
Among them, the protection (access permission) of the parent directory might not allow you to modify it. You should check the Clearcase permission of the directory "fieldAudit". You can do so by right-clicking on the directory and look at the Clearcase property. If you are not the owner and if the group you belong to does not have the permission to modify the parent directory, you might get into this type of issue. In order to modify the access permission of the parent directory, you can will have to use the "cleartool protect" command, either as the VOB owner or either as the owner of the element.
The command would then be (for Linux/Unix):
cleartool protec -chmod 770 fieldAudit
What matter is the 7 for the group. You could give 775 or 777 (which would not be safe) depending on the policies for your VOB. Your Clearcase administrator should be able to help you on that one.
I don't have proper explanation for this issue. A senior person from another team helped and i couldn't follow what he did exactly. Basically he deleted the file from my view and recreated it. He did this a couple of times.Sorry I am not able to answer this properly.
I have been using XCode with subversion for some time now, no problem was caused when I was using it as a single developer (I was using 2 commands only, commit and add).
But now I have to share the code with another developer (who has never used any kind of version control) and integrating/merging the code has become a nightmare. No problem occur when we are integrating/merging .h/.m files but as soon as it comes to ".nib", "xcodeproj" and ".xcdatamodeld" files, we really don't know what to do.
Whenever we try to merge "xcodeproj", project was getting corrupt and merging ".xcdatamodeld" was kind of impossible for us.
So I was wondering if someone can share his/her experience on how to effectively use subversion/git/mercurial with XCode 4.0 in multiuser environment? or share a link, which can explain how to use subversion effectively in multiuser environment.
Thanks.
Are you doing this using Subversion? For 90% to 99% of the files in your repository, the standard Subversion workflow of checkout, edit, commit works well. However, for some types of files such as JPEGS and GIFS simply don't merge well. In this case, you'll have to do it the way we use to in the old SCCS and RCS days: Before you can edit and commit a file, you must lock it.
Locking a file prevents others from editing the same file and committing changes while you're doing your work on the file. It's crude, but it works. In Subversion, you can always lock any file you're editing, but if the file has the property svn:needs-lock on it, it will be checked out as read-only. You have to lock the file before editing it to make it writable, and you're not allowed to commit the file unless it is locked.
So, for those files, set the svn:needs-lock property on it.
You can automatically set this property on all newly added files (depending upon suffix) via setting the auto-properties in your Subversion client configuration.
And, if you really, really want to make sure that all .nibs and xcodeproj and all of the other flies of these types have svn:needs-lock set on them, you can use my pre-commit hook which will prevent these files from being committed unless this property is set.
There is no failsafe way to merge these kinds of files that I am aware of. So you will have to
try to ensure that only one person is changing these files at a time. That won't work always, so just log what you changed in the file with the commit message. Then if there is a conflict, you can manually resolve it by taking the version that changed more of the file and redo manually what the other person did.
That's normally not a big deal, like adding a new source file to an .xcodeproject, or changing the alignment of an element in a .nib. It's becoming a problem if your project is huge or your nib is containing the whole interface. For it to work well (which in practice it does), you need to split up your projects into sub-projects if they grow too huge.
I had the same problem with 2 other developers Xcode with git. Unfortunately, Xcode project files are an XML file, tracks file included in the project as well as setting. I'm not certain, but I think .nib files are also XML files as well. Someone can correct me on that.
Git did a great job at merging the Xcode project file, and never really had any problems with our *.nib files either. The only time we did have a problem is when we both added/removed files with the same names, or someone did a lot of heavy removing and adding of a lot of files.
The only way we solved this was to have each other push ann pull as soon as we added/removed files. So that way the person had the latest files, and didn't add them in their own repository then pull the latest commit which had the same file in it. Or they work adding changes to a file that was removed or renamed.
That is the best solution we found, as soon as we added or removed a file have everyone else in the team pull. Not a great solution btw. However, you should be committing often anyways.
So you know a lot of Mac apps use "bundles": It looks like a single file to your application, but it's actually a folder with many files inside.
For a version control system to handle this, it needs to:
check out all the files in a directory, so the app can modify them as necessary
at checkin,
commit files which have been modified
add new files which the application has created
mark as deleted files which are no longer there (since the app deleted them)
manage this as one atomic change
Any ideas on the best way to handle this with existing version control systems? Are any of the versioning systems more adept in this area?
Mercurial in particular versions based on file, not directory structure. Therefore, your working tree, which is a fully-fledged repository, doesn't spit out .svn folders at each level.
It also means that a directory that is replaced, like an Application or other Bundle, will still find it's contents with particular file names under revision control. File names are monitored, not inodes or anything fancy like that!
Obviously, if a new file is added to the Bundle, you'll need to explicitly add this to your repository. Similarly, removing a file from a Bundle should be done with an 'hg rm'.
There aren't any decent Mercurial GUIs for OS X yet, but if all you do is add/commit/merge, it isn't that hard to use a command line.
For distributed SCM systems like git and mercurial shouldn't be a problem as Matthew mentioned.
If you need to use a centralized SCM like Subversion or CVS, then you can zip up (archive) your bundles before checking them into source control. This can be painful and takes an extra step. There is a good blog post about this at Tapestry Central:
Mac OS X bundles vs. Subversion
This article demonstrates a ruby script that manages the archiving for you.
An update from the future:
If I recall, the problem with managing bundles in SVN was all the .svn folders getting cleared each time you made a bundle. This shouldn't be a problem any more, now that SVN stores everything in a single .svn folder at the root.
Bringing this thread back to daylight, since the October 2013 iWork (Pages 5.0 etc.) no longer allows storing in 'flat file' (zipped), but only as bundles.
The problem is not the creation of version control hidden folders inside such structures (well, for svn it is), but as Mark says in the question: getting automatic, atomic update of files added or removed (by the application, in this case iWork) so I wouldn't need to do that manually.
Clearly, iWork and Apple are only bothered by iCloud usability. Yet I have a genuine case for storing .pages, .numbers and .keynote in a Mercurial repo. After the update, it blows everything apart. What to do?
Addendum:
Found 'hg addremove' that does the trick for me.
$ hg help addremove
hg addremove [OPTION]... [FILE]...
add all new files, delete all missing files