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.
Related
When using Git and the Git GUI, I'm used to highlighting one or more lines, right-click and use the selection as what I want to check-in. This way, I can for example create two check-ins from the same file: say fixed typos (not interesting) and new functionality (interesting for someone that checks the version history).
In Visual Studio, I can only check in the entire file, but not specific lines. In order to do this, I could:
copy the server-version and my local version to Notepad++ as two files,
compare the two files,
copy the selected changes to my reverted local version that I want
to check in,
then check in the current changes,
and finally copy all the remaining changes to my local version so that all
changes are back in my local version. (rinse and repeat for all separate changesets)
This is... not ideal.
Is there a way (perhaps via a client-side plugin) that I can select a part of a file to check-in, but leave the remainder un-checked in?
You basically want to do a version control in other words. There are lott of them like git,SVN they are designed to do what you want.
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.
Basically, I want one of my folders to appear above the other folders as a type of "special folder", similar to how Properties has it's own special place even though it's a folder, same with App_Data, etc.
Is this possible?
By default, Visual Studio doesn't support adding special project folders. The Properties folder is hard-coded to behave the way that it does.
However, anything is possible with code. You could build an extension to do this, but it wouldn't be simple. You'd probably need to mess around with the IVsHierarchy or even implement a project subtype.
Basically, I want one of my folders to
appear above the other folders as a
type of "special folder", similar to
how Properties has it's own special
place even though it's a folder, same
with App_Data, etc.
Is this possible?
Yes:
Do it manually through the IDE
Write your own script to
generate/modify your *.sln/*.vcproj
For (1) "manual" on solutions in the IDE: Solution Explorer, right-click on Solution node==>Add==>New Solution Folder.
While typically the folders are sorted alphabetically (I'd insert a leading underscore to force your special folder to the top), solution folders inserted manually on my MSVS2008 leave the new folder "at the top", even though it should have bumped down when alphabetically sorted. However, folders under a Project (which are called "Filters") are always sorted alphabetically, and added similarly from the right-click, and then you can modify their "filter properties" with file name globs for what you want in there (e.g., add a filter glob for "*.MY_EXTENSION1;*.MY_EXTENSION2").
We chose (2), and we generate our own *.sln and *.vcproj, adding our own folders/filters. I've not seen any utilities on the web to help with that (so we had to write our own). The formats are not too hard to reverse engineer, but it's largely undocumented XML, so you have to experiment. There are only a couple good web articles explaining what's in the file, like this one:
http://tim.oreilly.com/pub/a/dotnet/excerpt/vshacks_chap1/index.html?page=4
On the "bright side", the files are only XML, so in developing our scripts we merely made changes through the IDE, saved, and compared the "diffs" for what change we want. Those changes are what our scripts insert when we modify our files. So, if you modify the file manually, you can similarly just "diff" the file to see what changed, and make your own script. (IMHO, this is the fastest and easiest route, since tools generally do not exist to manipulate these files.)
Tools like CMake and QMake generate *.vcproj/*.sln, but don't really do the folder customization thing like you're talking. However, we look at their output too, because, "there's more than one way to do things" in these files, and the files seem to have many undocumented features for doing different clever things that somehow these tools have "discovered" (so you can try to copy their generated output).
We found the .NET APIs to work with these files as too much work, and not really designed for that type of manipulation, but YMMV.
VS 2012 has a feature that I just found, and it solved this problem for me. It may not be new to VS.
Create a folder under the project with a leading "_" (to get it sorted first).
On the folder's properties set "Namespace Provider" to false.
VS (or ReSharper?) code analysis then does not complain that "the namespace does not match file location", which was the source of irritation for me that would otherwise have kept me from going this route.
Although there is no easy way to add Custom Folder, there is an easy way to "steal" Properties custom folder.
Add a regular folder to the project. For example MyCustomerFolder.
Open proj file xml. Find line
<AppDesignerFolder>Properties</AppDesignerFolder>
replace with
<AppDesignerFolder>MyCustomFolder</AppDesignerFolder>
Reload the project.
Now you've got a custom folder, that will always stick to the top.
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.
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.