We have a StarTeam view that has two files that are in the "Unknown" state – does anyone understand why they are in this state and/or how we can get them out of the state?
Is deleting them and re-adding them with a different name the only solution?
Note that if you check out these two files (regularly or using “force checkout”), they will always be listed as “Unknown” (annoying).
Thanks.
More info based on Craig's suggestions below:
a) Calculating file status using MD5 checksum: same results ("Unknown" status)
b) These two files in question have only one revision on the server. I'm not sure if this is because our CM group attempted to fix the issue by deleting and recreating the files or if there really was just one revision. The files are text files.
c) I tried deleting the files on my local machine and refreshing the status. When I do this, instead of seeing the two files listed as "Unknown", I see a total of four files listed with a status of "Missing". There are two entries listed for each file - each pair has the same file name, folder path, "modified by", and "file stamp at time of check in". I have no idea why each file is listed twice. If I select each entry in a pair and select "Compare Contents", my diff tool says they are identical.
I have this same weird issue with the four files whether I use the MD5 checksum compare or non MD5.
If I try to checkout all four of the Missing files, I get two alerts prompting me to merge the files. I say no, the files are now on my local file system and the status is back to where I started - two files listed as "Unknown".
Craig's update:
You're definitely on to something. I moved each of the duplicate items to another directory. That immediately solved the issue in that I now could checkout the four items (two in same dir and two in new dir) without any "Unknown" items. I then deleted the two items that I moved to the new directory.
In doing this, I saw some more info. We somehow have a directory structure like this:
Parent_Dir
--SubDir1
--SubDir1
--SubDir1
--SubDir1 <- Two items were here
--SubDir1 <- Two items were here
--SubDir2
--SubDir3
--SubDir4
--SubDir5
Somehow we have five sub directories with the same name and these two files in question existed in two of the sub dirs with the same name.
The issue appears to be resolved. Do you think I should manually delete the extra sub directories?
Thanks to Craig this issue appears resolved. I have no idea how this situation was created (anyone?) but.. we're good now. Thanks Craig!
It would be a huge mistake to delete the files before you determine where the problem lies. Deleting and re-adding the file would kill the history and any links to the file. It also might not fix the problem, due to the way that StarTeam works internally (with a Native-II repository, anyway). Deleting the file and re-adding the identical file will not actually update anything in the repository, except the pointers to that revision. The revision itself would have stayed there when you deleted the file, and re-adding it would just create a new pointer to that revision.
If you haven't done so already, I strongly recommend telling StarTeam to calculate the file status using an MD5 checksum. Do this in the client via Tools->Personal Options->File->Use file checksums to calculate status. Then try update status again. This is not the default setting (in at least some versions of StarTeam), so it's worth checking. If you have not already done this, it may, by itself, fix the problem.
The first thing to do is to determine if the revision is valid on the server. If the files are text, the easiest way to do that is to compare contents between that revision and the previous revision. If it does turn out that the revision is corrupt, then the best solution would be to check out an earlier revision, and then force check in. This way you preserve the history of the file.
If the file appears to be OK on the server, then test it locally, by comparing contents. If the file is corrupt locally, do feel free to delete the file locally and then check it out again. Unlike deleting the file on the server, you don't lose anything by doing this, except local revisions.
If these suggestions do not fix the problem, I still would not recommend deleting the files on the server. Tell me the results of your investigations back here, and we'll see where we can go from there. It is, in my opinion, nearly always mistake to kill history.
Update
Based on the updated information in the post, I'm getting a better sense of what is going on here. It is likely that there are two items which point to the same file, and have the same name. "Item" is a concept in StarTeam related to the fact that a single file, change request, requirement, etc. can live in multiple places at once. For example, you can have a single file in two different views or projects.
Generally, you do not have the items with the same name in the same folder. But it can happen. And that probably explains the "Unknown" status. When you tell StarTeam to compare the file on disk with the item of the same name on the server, perhaps it can't figure out which item it should look at.
The first thing I would try is to try and drag one of the two items somewhere else. If that fixes the problem in the folder in question, you can delete the item elsewhere, without affecting the item in the folder. If, on the other hand, dragging one of the items elsewhere causes them both to move, it's easy to drag the item(s) back to where they came from.
Update 2
Do you think I should manually delete the extra sub directories?
Yes, but just as with the files, move them first, and make sure the subdirectories you'd like to keep are unaffected before deleting them.
A good way to identify this issue if it comes up again is to click on the root folder, add folder path to the shown columns, then click the all descendants button. Sort the files by name, and look for the unknown files and see if multiple files of the same name are checking out to the same path. Usually this is the result of a mistaken share, addition, or a change in folder check-out path.
As it is undetermined what order StarTeam will check files out, having two different files with the same name pointing to the same local location is a mistake. The 2005R2 native Windows client and Cross Platform client would pull files in a slightly different order, causing views with this issue to produce checkouts with different files.
There are a few ways to legitimately end up with this situation - keeping multiple branches of a single file on the tip and designating which to use by view label is a common one. StarTeam is one of the few VCs that can handle multiple references like this.
Separately, if you can help it, never delete and re-add a file. 99% of the time, it isn't what you want to do. Re-adding a file to the server gives it a whole new archive in the database and it will not be tied in any way to existing shares of that file. You will also lose all of your revision history. Instead, look for ways to move files. And if you have multiple files with the same name and content on your server, it is usually a good idea to make an effort to share the file to the various places it should exist rather than re-add it. This will make sure your changes propagate so you don't need to check-in fixes multiple times.
Were those files added twice? You can add the same file multiple times which could result in this error. Also, check the Reference tab - are these linked files to elsewhere in the repository?
Could that be the files or their status got corrupted on the server? In that case, delete and re-add is the only way.
Related
I'm hoping that this is in the right spot.
Basically, I have a set of files which are versioned in an SVN repository, and I am using TortoiseSVN. These files all need to be renamed so that their new name is equal to their current name, plus a prefix added to the front.
Tortoise has the ability to rename the files, but it must be done manually, file by file, through a GUI menu, and I would prefer a less tedious and less time-consuming solution.
I have seen on this site examples which use Windows-based solutions, but I do not expect these to work, as they would not change the filename through TortoiseSVN but through Explorer, which would cause TortoiseSVN to not recognize those files as being equivalent to the originals, even if we recognized them as such.
I saw another question, linked here: (tortoise svn mass rename files merge)
In which the asker says that the files were renamed with a windows tool and thus SVN did not recognize them, and the solution offered was to write a new script which would pick up the old name, replace it with the new name, and repeat for each entry. However, unless I'm misreading it, that solution would require going in and specifying the old and new name for every entry, which from my perspective could be just as time-consuming as doing the manual option in TortoiseSVN.
I considered another possibility in that I could use windows command line to make a copy of every file in the directory, renaming the copies to fit. Then I would SVN delete the old files and SVN add the new files. This would achieve the rename, but then the history association would be disrupted, as it was technically no longer the same file.
The problem I'm running into as I read different questions asking similar queries is that they seem to be built around specifying the start file name and the end file name for each entry. I want to do a blanket rename on every file, without needing to consider the file name before or after the execution.
As such, my investigation has brought me to ask this question: Given a set of known existing Files F, and a known, constant prefix P, can TortoiseSVN be made to automatically update every entry in F with the prefix P, but in a way that TortoiseSVN recognizes as its internal 'rename' process (rather than an exterior process which would, in its perspective, replace, rather than change, the given file), and without having to also define the resultant end name of each file in F (thus no need to specify old and new filename for every entry), so that each file can be updated without needing manual intervention for each one? Thank you for reading.
For the last 2 days I've been trying to make my single-file document into a package, but I can't get it to work. In the documentation it states the preferred way is to use NSFileWrapper. I've tried it but it's just such a unintuitive way of handling files.
I guess to update a file I need to delete the file wrapper from it's directory, create a completely new one and add it again to the directory. I haven't found anything that explicitly states it, but I guess I should update the file only when fileWrapperOfType:error: is called.
As NSFileWrapper keeps everything (at least once loaded) in memory, this means that I'll have the old version and the new version at the same time until the user (or autosave) saves the file.
It seems like NSFileWrapper shouldn't be used for big files, but I think it's better if all the files that are needed by the document are inside the package(can be copied to another Mac/iPhone/iPad without errors) and I don't want to limit the user on how many/how big the files can be.
When using a manual URL-based saving mechanism, I end up getting corrupt packages, as the destination directory is always a temporary one, and I couldn't find any information on how to merge them. Every time I manually save the document without any changes, an error occurs, as I don't write anything to the temporary directory. But I don't see a reason in writing/linking everything to the temporary directory, only for it to be copied/'un'-linked back to its destination.
As I can't seem to find the right answer, what is the best-practice for saving and restoring big packages with many/big files in them?
I want to pull from a git repo in Windows which has two directories, named Foo and foo. Both the folders have different contents.
As Windows is case insensitive and doesn't allow folders with same name but different case, how do I push to the git repo?
Short answer: You can’t do this easily.
By default, this is a restriction of the Windows subsystem. Unless you use lower level system calls, Windows cannot differ between different casing; so even if Git is able to keep track of the differences, it can’t communicate these difference to the file system.
As pointed out in the comments by phuclv, it is possible to reconfigure the Windows kernel to be case sensitive. In Windows 10, this even works for individual folders, so you could use this to add compatibility where you need it. However, the case sensitivity per folder is not inherited, so you will need to manually change this for the folders that Git creates which might be a bit bothersome and makes this mostly a workaround.
Instead, you could make the whole file system case-sensitive but that might have additional implications, so just be careful if you want to do that.
Also note that even if there is support for case-sensitive content on the lower level, most Windows applications, including built-in Windows tools, will probably not be able to work with this. So this will only allow you to work with these files from certain tools. My guess would for example that most GUI based Git tools simply won’t work here.
If you don’t want to make these modifications, then what you maybe also could do is create partial commits where you just add files to the correct folder (you need to rename it in-between to get the different casing). But that will be very impractical.
In my opinion, the best solution is to simply avoid using multiple files on folders with conflicting names. Even on case-sensitive systems, this will only make things more confusing. By avoiding this completely, you also make it easier for all other developers to interact with the project.
As a follow up to poke's answer, you need to split those directories apart into different names, or merge them correctly into one with the same name, depending on your needs of course. They can't have the same name other the case and have it work in Windows (in a clear and obvious manner anyway).
I accidentally ended up in this same boat. I'm not sure how, as I was using Windows the whole time, but at some point I changed the case on a directory in the repo and some files ended up remaining in a directory with the "old" name and some in one with the "new" name. On my Windows machine they were all under the new name, but I found this problem when I pulled the repo into Linux, and confirmed the split when I looked in my remote repo.
To fix this, I first cloned the to a separate location on my Windows machine. Doing so, all the files were there in one directory again, as apparently the two directories just get merged. I then renamed that problem directory to "temp", (using the TortoiseGit "rename" operation). Then, I cloned the repo to yet another location. At that point, the two directories were in fact split apart in Windows. I had a "temp", plus the directory with the "old" name.
As I really did want them in one directory (on all platforms!), I moved the files out of the old named directory into "temp", then deleted the "old" directory. Next, I renamed temp (using the TortoiseGit "rename" operation again) to the name I wanted everything within, committed and pushed again. Finally, I pulled the changes into my original repo (my Linux one) and checked what was on the remote. Everything was finally in agreement, so I deleted those temp clones and called it a day.
I've got an Xcode project under git and I've got a "experimental" branch off of my "master" branch. Both branches have diverged since the branch (so no fast-forwarding!), and I am merging "experimental" into my "master" branch.
I've setup a .gitattributes file to treat a particular Xcode file (project.pbxproj) as binary, as it should be treated as such. However, I'm not sure exactly how to merge it. I'm not sure what that particular file does, but if for example it handled which files were added to the project there's no way I can merge them, and therefore I'd have to manually add certain files back to the project (possibly not remembering them all). How do others handle this situation?
Also, I've read that you have to manually update binary files (obviously) or copy over different versions. However, once I'm into the merge process the file in my working copy is the "master" version. How can I access the "experimental" version? I can't check it out as it would disrupt the merging process.
Thanks for your time!
In general, for binary files, I recommend a copy-merge type of .gitattribute directive.
That is, I just copy the file coming from the remote end of a merge.
For .pbxproj files however, that may not be a good option, as described here.
Wrapping these files would only make the problem worse as far as I can tell - as you wold be completely unable to merge changes.
While you can merge project files in some cases, it's not something that you should
count on being able to do. The basic recommendation is to avoid editing the project files at the same time as someone else.
I like versionning projects files (like the ones for Eclipse), only if I know they are:
not modified that often (certainly not by each developers)
only using relative paths
no data specifics to one workstation
In short, if those files are not to be merged (or will only be trivial to merge), I want them in a VCS. In your case, that may not be so useful to have them in said VCS in the first place.
Note: as mentioned in the Git manual:
During the merge, the index holds three versions of each file. Each of these three "file stages" represents a different version of the file:
$ git show :1:file.txt # the file in a common ancestor of both branches
$ git show :2:file.txt # the version from HEAD.
$ git show :3:file.txt # the version from MERGE_HEAD
Our VB6 guy was part of the last RIF (Reduction in Force). The work he did has been split between me and another developer. We often are both are making changes to projects at the same time. This isn't a problem with CVS since we are working in different areas. However VB6 seems to modify the Reference section and change the paths each time either of us touches a project. Since we don't have the exact same path setup for out source trees we run into merge conflicts on the vbp file all the time.
Is there any way around this other than the obvious method of changing our setup so we have the same directory structures?
I would suggest two things:
Don't commit the .vbp unless you add a file to the project.
Mark the .vbp as read-only and check it in as such into your repo. When users check it out, it should still be read-only which will prevent changes to reference paths (and seemingly random reordering of the file) from being saved. When you have to make a change to the project--make the file read-write, save the change and then make it read-only again before committing.
Depending on your version control system, it is possible to automate this problem away. Both Subversion and Mercurial support hooks - scripts that are triggered by certain events, like check out, update, or commit. We wrote a fairly simple script that was triggered on commit: it looked to see if there was a .vbp in the commit package, and if there was, ran a "normalisation" routine that
put all the .cls/.bas/.frm files at the top of the .vbp, in alphabetic order
put the references section in alphabetic order
lower-cased the reference paths
The rest of the file is left alone, since it's only the first three sections that VB seems to delight in messing about.
Consequently, most of the time when you commit, and haven't made any substantive changes to the .vbp, the hook script restores your .vbp file to a canonical, ordered, state (like a revert), which has the effect of removing it from the commit since it's no longer changed.
In the event that you do add a new file or reference to your project, the consistent alphabetical sorting of the VBP lines means that merge conflicts are avoided since your VC merge algorithm can easily and correctly detect the changes.
We wrote our script in Javascript and execute it using Windows Script Host since, for Windows boxes at least, this removes the dependency on an interpreter like Perl/Python.
Hooking up this script to new VB projects is a 30 second job. The advantage over other manual approaches is that you don't have make any conscious effort to deal with the VBP file. Just commit it with everything else and the script takes care of the rest.