Vault client/server is version 3.1.1.3506
Hi, we have a question concerning shared files. Let's say we have this folder structure
Documents\Share1
Documents\Share2
I place a file in Share1, and share it with Share2
I right-click on the file in Share1, and chose Edit... then I start editing the file.
I quit for the week, and turn off my computer.
On monday, I want to continue editing the file, I go to Share2 and right-click, chose Edit. (obviously not the same folder as friday, but I was allowed to edit) I happily continue editing on some other chapter, not noticing that I use the wrong version of the file. I, however do see it when I try to check in from the wrong folder, which isn't allowed. Now I'm stuck with two edited versions of the same document.
Is this a bug or a feature? I'd say it's a bug. The Edit option should be disabled from the Share2 folder when I started the editing from Share1.
Regards,
Patrik Oscarsson
Editing shared file
Moderator: SourceGear
My suggestions first was to set Require Exclusive Locks from the Admin tool.
As for your current changes, if you check in one file first and then perform a merge changes, then you can check in the second one as well.
Linda and I were doing some testing with this to make sure that it is behaving the way it should. We should have some more information soon.
As for your current changes, if you check in one file first and then perform a merge changes, then you can check in the second one as well.
Linda and I were doing some testing with this to make sure that it is behaving the way it should. We should have some more information soon.
After re-reading, I think one of the things that is causing problems is that you are just editing a file instead of checking it out. You will either want to check out a file before editing, or have the Require Check Out option set under Options-Concurrent Development Style. That way a file will be shown as checked out. You may also wish to turn on the field to show where a file is checked out to so that it is viewable. Also, the check-out option will be grayed out if one is exclusive locking and requiring check outs.
Depending on your development style, you may wish to use branching instead of sharing. Eric Sink's Source Control How To gives a pretty good indication of how these features are intended to be used: http://software.ericsink.com/scm/source_control.html
I did perform tests, wrote up the results, and ran them past the developers to make sure it was behaving in the fashion they wanted, and they were fine with its functionality. I can put in a feature request if you want something different.
Depending on your development style, you may wish to use branching instead of sharing. Eric Sink's Source Control How To gives a pretty good indication of how these features are intended to be used: http://software.ericsink.com/scm/source_control.html
I did perform tests, wrote up the results, and ran them past the developers to make sure it was behaving in the fashion they wanted, and they were fine with its functionality. I can put in a feature request if you want something different.
Hi Beth.
In our company we have some documents that are shared among several projects, a branch is not a solution since updates should affect all projects.
We do have the "Require Check Out" option set both in the admin tool, and in the client, but that only applies when there are more than one editor at a time. We also have the "Checkout location" shown in the client, but that helps a little, it's easy to right-click Edit anyway.
If we have to check out a file before edit, then the user must open windows explorer, find the file and then edit, that will upset our employees. Edit is just perfect until Word integration is available.
I did a more thorough test.
1. "Edit" the file from Share1 - The file is checked out, the file attributes "RA" disappears and the file is editable. Share2 still has "RA" attribute set.
2. "Edit" the file from Share2 - The file attributes "RA" disappears and the file is editable! Hey, this isn't allowed when doing a check out, why is it allowed when doing an Edit?
Please consider this once more time. This is really annoying. I would like to hear from your developers how they reason that the Edit functionality should be used. In my opinion it's a shortcut for "Check Out", "Open Explorer", "Find File", "Double Click".
Kind regards, Patrik
In our company we have some documents that are shared among several projects, a branch is not a solution since updates should affect all projects.
We do have the "Require Check Out" option set both in the admin tool, and in the client, but that only applies when there are more than one editor at a time. We also have the "Checkout location" shown in the client, but that helps a little, it's easy to right-click Edit anyway.
If we have to check out a file before edit, then the user must open windows explorer, find the file and then edit, that will upset our employees. Edit is just perfect until Word integration is available.
I did a more thorough test.
1. "Edit" the file from Share1 - The file is checked out, the file attributes "RA" disappears and the file is editable. Share2 still has "RA" attribute set.
2. "Edit" the file from Share2 - The file attributes "RA" disappears and the file is editable! Hey, this isn't allowed when doing a check out, why is it allowed when doing an Edit?
Please consider this once more time. This is really annoying. I would like to hear from your developers how they reason that the Edit functionality should be used. In my opinion it's a shortcut for "Check Out", "Open Explorer", "Find File", "Double Click".
Kind regards, Patrik
Patrik:
Sharing should always be used as a last resort since it can lead to unexpected results, especially from a source code point of view. I would always recommend branching / merging as the end user is in full control of the file's version in each folder. Now there are cases where Sharing is what you want. But it should be used with caution as sharing files within a code project may break builds or stop other people from compiling. With that said, your use case is a little different because it does not involve source files, but a binary document.
In any case, let's talk more about a share file's status, and the "edit" command.
When a file is shared, there will be multiple working folders from where you can edit the file. The file's status and checkout directory are available within the GUI client to provide visual clues about the file you are working on.
For instance, if you check out a shared file, and edit the file in working folder A, the status will change to "edited". However, the file in working folder B will have a different status - most likely it will be blank "". If you edit the file in a different location than the checkout, that shared file's status is set to "Renegade". These all serve as visual hints to the end user to let them know if they are working on the checked out file.
As for the "edit" command, this command may be better described as "edit the working folder's copy". It is loosely coupled to the repository because a checkout can be invoked from here, but this command's main function is to remove the read-only attribute (if set), and launch an editor. Sharing does not factor into this, since there may been times where a shared file needs to be renegade in order to make a change that is build or compilation related.
I hope I've answered your questions related to Share.
Sharing should always be used as a last resort since it can lead to unexpected results, especially from a source code point of view. I would always recommend branching / merging as the end user is in full control of the file's version in each folder. Now there are cases where Sharing is what you want. But it should be used with caution as sharing files within a code project may break builds or stop other people from compiling. With that said, your use case is a little different because it does not involve source files, but a binary document.
In any case, let's talk more about a share file's status, and the "edit" command.
When a file is shared, there will be multiple working folders from where you can edit the file. The file's status and checkout directory are available within the GUI client to provide visual clues about the file you are working on.
For instance, if you check out a shared file, and edit the file in working folder A, the status will change to "edited". However, the file in working folder B will have a different status - most likely it will be blank "". If you edit the file in a different location than the checkout, that shared file's status is set to "Renegade". These all serve as visual hints to the end user to let them know if they are working on the checked out file.
As for the "edit" command, this command may be better described as "edit the working folder's copy". It is loosely coupled to the repository because a checkout can be invoked from here, but this command's main function is to remove the read-only attribute (if set), and launch an editor. Sharing does not factor into this, since there may been times where a shared file needs to be renegade in order to make a change that is build or compilation related.
I hope I've answered your questions related to Share.
Jeff Clausius
SourceGear
SourceGear
I did want to add a comment on this one part. Once a file is checked out, you don't have to go to the folder to edit it. You can then select edit from inside Vault. The point I was trying to make was to make sure the file had a check-out before editing, but both can be done from within Vault. Also, if you want to go right to where the file is, you can use the Browse Working Folder function.If we have to check out a file before edit, then the user must open windows explorer, find the file and then edit, that will upset our employees. Edit is just perfect until Word integration is available.