Rename Folder Problem
Moderator: SourceGear
-
- Posts: 11
- Joined: Thu Feb 26, 2004 12:28 pm
Rename Folder Problem
Using Vault 3.1.1.3506... there seems to be a bug with the folder Rename.
If you rename a folder in the Vault and do a GetLatestVersion, you'll have both the new and old folder's locally.
i.e.
-Create a Folder Named: Bob
-GetLatestVersion, you'll see a Bob folder on your local drive
-Rename Bob to Doug
-GetLatestVersion, you'll see both Bob and Doug on your local drive
Rename works fine for files...
If you rename a folder in the Vault and do a GetLatestVersion, you'll have both the new and old folder's locally.
i.e.
-Create a Folder Named: Bob
-GetLatestVersion, you'll see a Bob folder on your local drive
-Rename Bob to Doug
-GetLatestVersion, you'll see both Bob and Doug on your local drive
Rename works fine for files...
Actually, the behavior is the same for both folders and files. A rename does not change the name of the file or folder on disk. You need to do a Get to get the renamed file or to create a folder with the new name.Rename works fine for files...
We do have a bug logged to make Vault smarter about this. I'll add your comments.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
... Same thing for deletes: Delete a file from Vault and it will remain in the working folder, this is desired behavior, no?
I mean, if you rename a folder in Vault, that does not necessarily mean you want to rename it also on the physical drive... For example if you rename the folder \devel\internal to \devel\int, you might still want to keep the "internal" name in your physical hard disk (via a working folder name for example). I guess the real problem comes up when the renamed folder contain files that are not part of source control... It may move too many files over to the new name.
Well, as long as the user is informed of what is going on, it might be a good thing to more closely mirror what is on the source control server.
I mean, if you rename a folder in Vault, that does not necessarily mean you want to rename it also on the physical drive... For example if you rename the folder \devel\internal to \devel\int, you might still want to keep the "internal" name in your physical hard disk (via a working folder name for example). I guess the real problem comes up when the renamed folder contain files that are not part of source control... It may move too many files over to the new name.
Well, as long as the user is informed of what is going on, it might be a good thing to more closely mirror what is on the source control server.
gabriel magana-gonzalez
-
- Posts: 11
- Joined: Thu Feb 26, 2004 12:28 pm
Folders not Files
[quote="lbauer"]
You need to do a Get to get the renamed file or to create a folder with the new name. [/quote]
If you noted my original chain of events, you'll see I said do a Get after the rename, with a file this works .. the file is renamed on the local disk.
BUT if you try to rename a folder, you it doesn't rename the old folder, it creates a new one.
You need to do a Get to get the renamed file or to create a folder with the new name. [/quote]
If you noted my original chain of events, you'll see I said do a Get after the rename, with a file this works .. the file is renamed on the local disk.
BUT if you try to rename a folder, you it doesn't rename the old folder, it creates a new one.
What I was describing is this:
I have FileA in the database and and there is also a copy of FileA in my working directory.
I rename FileA -> FileB in the database. I do a get on FileB. I now have FileB AND FileA in my working directory. I got the renamed file, but Vault did not delete the original file in my working directory.
Are you seeing something different?
I have FileA in the database and and there is also a copy of FileA in my working directory.
I rename FileA -> FileB in the database. I do a get on FileB. I now have FileB AND FileA in my working directory. I got the renamed file, but Vault did not delete the original file in my working directory.
Are you seeing something different?
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
-
- Posts: 11
- Joined: Thu Feb 26, 2004 12:28 pm
Files Folders and different behaviours
Okay, here's what I see/do:
1) Add a file called FileA.txt to a vault folder
2) Get Latest Version on the Folder
3) On my local drive I have: FileA.txt
4) In the Vault Client, I rename FileA.txt to FileB.txt
5) Get Latest Version on the Folder
6) On my local drive I have: FileB.txt ONLY
However, if you do things slightly differently you get differnt results
1) Add a file called FileA.txt to a vault folder
2) Get Latest Version on the File - FileA.txt
3) On my local drive I have: FileA.txt
4) In the Vault Client, I rename FileA.txt to FileB.txt
5) Get Latest Version on the File - FileB.txt
6) On my local drive I have: FileA.txt and FileB.txt
See the Problem is doing a GetLatestVersion on the parent folder VS. the file itself.
The problem that started this is that Folders only behave in the 2nd scenario fashion, not the first, as I was expecting .. thereby leaving my working folders cluttered with junk.
1) Add a file called FileA.txt to a vault folder
2) Get Latest Version on the Folder
3) On my local drive I have: FileA.txt
4) In the Vault Client, I rename FileA.txt to FileB.txt
5) Get Latest Version on the Folder
6) On my local drive I have: FileB.txt ONLY
However, if you do things slightly differently you get differnt results
1) Add a file called FileA.txt to a vault folder
2) Get Latest Version on the File - FileA.txt
3) On my local drive I have: FileA.txt
4) In the Vault Client, I rename FileA.txt to FileB.txt
5) Get Latest Version on the File - FileB.txt
6) On my local drive I have: FileA.txt and FileB.txt
See the Problem is doing a GetLatestVersion on the parent folder VS. the file itself.
The problem that started this is that Folders only behave in the 2nd scenario fashion, not the first, as I was expecting .. thereby leaving my working folders cluttered with junk.
I think changes like rename and delete need to be mirrored in the working directory even while they are pending.
If there is no working directory, then fine, don't worry about it.
If the pending rename or delete is undone, then it should be undone in the working directory as well.
If a Get Latest is done that includes a pending rename, any changes to the file with it's original name should be merged with the renamed file in the working directory.
The idea is that your working directory should mirror what the repository will look like after you commit all of your changes. This allows you to test that your changes really work, and rely on Get Latest to make sure your tree is up-to-date for your last test before you commit.
Without this behaviour you'd have to remember to track down all pending renames and deletes and do them by hand in your working folder after doing a Get Latest.
Mike
If there is no working directory, then fine, don't worry about it.
If the pending rename or delete is undone, then it should be undone in the working directory as well.
If a Get Latest is done that includes a pending rename, any changes to the file with it's original name should be merged with the renamed file in the working directory.
The idea is that your working directory should mirror what the repository will look like after you commit all of your changes. This allows you to test that your changes really work, and rely on Get Latest to make sure your tree is up-to-date for your last test before you commit.
Without this behaviour you'd have to remember to track down all pending renames and deletes and do them by hand in your working folder after doing a Get Latest.
Mike