I am a newbie to perforce and recently started experimenting. I am normal developer with write privileges and was able to delete the entire depot. How can i avoid this while retaining write privileges?
Is there any other way other than Trigger and permission table?
Also, if the developer has deleted a [depot? -msw] and submitted the changelist, how to recover during the following scenarios:
Checkpoint and journal have not been created?
Workspace synced to the depot, and has cleared the workspace eventually.
But the developer is able to view files through the changelist. [??? -msw]
I request someone to clear-up these things for me.
If you give a user write privileges to a directory in Perforce, there is no way to prevent them from deleting it. You can mitigate the damage they can do by narrowing their permissions. Only give them access to what they need, rather than the entire depot.
When you delete files in Perforce, they are not gone, they are just hidden. You can display them with the "Show Deleted Depot Files" option on the filter menu.
They can easily be restored using the "Rollback..." or "Back Out Submitted Changelist N" options.
Files are only truly gone when you use the obliterate command, to which only super users have access.
Related
I am using Bohemian Coding Sketch to design websites. All my files are in Dropbox, shared with a team (another designer). Most of the time we are working together with same files — one is editing, another is watching and discussing. I think this is a pretty common scenario these days.
When files are changed by the other, they get changed on my disk by Dropbox. And after that things go worse. Sketch gives this warning:
Any choice I make is bad, because:
Revert changes. It does not mean "revert to a file on disk". It actually means "revert to a file state, that was when you last opened the file".
Save. Means "overwrite with your changes work from other designer".
Cancel. Means "Do nothing"
Since this dialog opens when I close the Sketch, I have no option, but to shoot myself in a foot.
Does someone have a solution? One proposed is to copy files from shared folders to view them, which works but smells funky...
Ok. So this is a workflow issue. Sketch doesn't have or offer the ability of multiple user versioning. So it's a highly bad idea for more than one person to be working on the same file.
You're two choices are...
Have the other artist create a duplicate file. Not only does this insure proper versioning (something you guys should be keeping track of), but it also allows for the lead to then take the best ideas from each and combine them into a new versioned file.
Purchase an asset management system like AlienBrain. It handles a lot of the tedious processes of versioning for multiple artists in a studio. However I'm not aware of its integration with DropBox.
My colleague and I are participating in a huge project located in Accurev. We've already created own workspaces backed with some stream (let's call it zzz-stream) which is used by many other participants, not only by us.
The point is that we want to exchange our work between our workspaces, make some changes, exchange again, etc. BEFORE making the changes accessible for others, i.e. in other words we don't want to propagate our changes until it is stable and tested, but we want be able to work on it together.
My idea was to create new stream (yyy-stream) backed with zzz-stream, and then change our workspaces to be backed with yyy-stream. But unfortunately I have no rights to create streams.
My second idea was to use a workspace as backed stream, but it doesn't work because Accurev can't use ws as backed stream.
Is there any solution for our problem?
UPD: I accepted Brad's answer as most detailed. However Accurev is too heavy and sluggish to be used effectively. So actually I prefer to use Git for internal needs over the accurev workspace. (see Accurev externally, git internally)
Your idea of creating the yyy-stream is the EXACT right way to do it. The other options are decent workarounds for one-off situations, but creating the extra stream is simple and is fully leveraging AccuRev's capabilities.
That being said, I understand that your admins have stream creation locked down. They of course want control, but should be allowing for maximizing developer productivity and not forcing workarounds like this. My guess is they have stream creation locked down to a particular group being enforced by the server-admin trigger. One common thing I have seen other large sites do is:
- allow streams to be freely created off of a list of acceptable streams (easy to do in the trigger)
- enforce naming rules on the stream creation. This is important to admins in large sites to keep things organized. Again, this is very easy to enforce via the server-admin trigger.
Bottom line, if this is a common situation, work with the admins to allow this capability as per the above. If they have any questions, they are more than welcome to contact AccuRev and we will help them out.
Your idea on using another stream for you and your peer is a good one and is commonly called a collaboration stream. If your site has stream creation locked down, you would need to work with your AccuRev administrator to make that happen.
Another option is for you and the other developer to pull the keeps from the other workspace into your own stream. This relies on both of you being diligent about doing keeps and then you can look at the history of the other developer's workspace to find the keep operation, right-click that transaction and then select Send to Workspace. The destination workspace must be your own.
A third option (more for a situation where you are in your workspace and know exactly what file you want to grab the other users changes)is to bring up the version browser for the file, right click and select history/browse versions. Look for the other workspace, highlight the version in that workspace, right click and select send to workspace. This will checkout that version into your workspace.
This is similar to the change palette suggestion but quicker if your looking to this on a file basis.
Another idea is to use different version control system (e.g. git or svn) over Accurev workspace to exchange the changes and keep our history separated from zzz-stream. (similar to Accurev externally, git internally) Only changed files should be added to other VCS, not whole project. Some merge problems occur though.
I have tried diligently to find bazaar user groups. I tried pressing the community tab on their website. There seem to be only mailing lists, but where does one start? The title says it all. I have tried revert, but since it was uncommitted, it did not work. The names of the files in question show up on 'bzr status' under 'missing'. the other files show up under 'added'. I am a bazaar rank beginner, and though I knew about commit, just forgot to do it after adding. Are the files well and truly lost, or is there a way to get them back? In the list you presented before answering, the only one which comes close to my situation is: "How can I un-delete an uncommitted", but unfortunately is for svn, not bazaar. This is my last shred of hope. I have held off doing commit now because I am afraid of losing the little which remains, since Bazaar says the are missing.
If bzr status says missing rather than removed, then the files were deleted from disk after they had been added but before a commit happened, I'm afraid.
Under these circumstances, bzr revert cannot help you; it will restore the working directory (or part of it) to the state of a specific revision. Without a commit, there is no revision to revert from, because the system has no record of your files.
If you have backups for your system, you may still be able to recover files from there.
Why isn't it standard behavior for Accurev to automatically run an "Update" upon opening the program? "Update" updates a user's local sandbox with the latest files from the building/promoted area.
It seems like expected functionality that the most recent files should be synchronized first.
I'm not claiming that it should always update, but curious as to why an auto-Update wouldn't be correct.
Auto-updating could produce some very unwanted results.
Take this scenario: you're in the middle of a development task, but you've made a mistake and need to revert a file that you just modified. So you open AccuRev, but before you have a chance to "revert to most recent version", you are bombarded with 100 files that have been changed upstream including the one you want to revert. You are now forced into the position of resolving all the merge conflicts before your solution will build, including the merge of your (possibly unstable) code in progress.
Requiring the user to manually update keeps a protective 'bubble' around the developer, allowing them to commit (keep) changes within their own workspace without bringing down code changes that could destabilise the work in their sandbox. When the developer gets to a point where his code is ready to share with others, that is the appropriate time to do an update and subsequently build/retest the merged codebase before promoting.
However there is one scenario that I do believe auto-updating could be useful: after a workspace is reparented. i.e. when a developer's workspace is moved from one part of the stream hierarchy to another. Every time we reparent we have to do a little dance:
Accept the confirmation dialog that reminds us (rather verbosely) that we need to update our workspace before we can promote any changes.
Double-click the workspace to view its files.
Wait for AccuRev to do a "Pending" search, to determine whether any file changes are waiting to be committed.
And finally, perform the Update.
Instead of just giving us a confirmation dialog, it would be nice if AccuRev could just ask us if we want to Update immediately.
I guess it depends on preference. I for one wouldn't like the auto-update feature.
Imagine you have a huge project and you don't want to build it every time you start Accurev. But you also can't debug because the source files and debugging info no longer correspond.
(I am newbie to tortoise SVN)
I have 2 folders in my tortoise SVN.
Each need a different set of authorization
(I do not want
people who have access to the first folder to have read / write access to the second folder).
How can I accomplish it? I noticed that all permissions are defined in a file in the root level.
This is covered in the Subversion Book section on Path Based Authorization. You can check out the link for more details, but I would just draw your attention to this part:
A lot of administrators setting up Subversion for the first time tend to jump into path-based access control without giving it a lot of thought. The administrator usually knows which teams of people are working on which projects, so it's easy to jump in and grant certain teams access to certain directories and not others. It seems like a natural thing, and it appeases the administrator's desire to maintain tight control of the repository.
Note, though, that there are often invisible (and visible!) costs associated with this feature. In the visible category, the server needs to do a lot more work to ensure that the user has the right to read or write each specific path; in certain situations, there's very noticeable performance loss. In the invisible category, consider the culture you're creating. Most of the time, while certain users shouldn't be committing changes to certain parts of the repository, that social contract doesn't need to be technologically enforced. Teams can sometimes spontaneously collaborate with each other; someone may want to help someone else out by committing to an area she doesn't normally work on. By preventing this sort of thing at the server level, you're setting up barriers to unexpected collaboration. You're also creating a bunch of rules that need to be maintained as projects develop, new users are added, and so on. It's a bunch of extra work to maintain.
Just to round the post of codeka up. You can't set (at least I never have found out how) any permissions for the repo in tortoise as it is the SVN client application. You would have to set the permission on your svn server. If you happen to be running VisualSVN Server (free) you can setup user rights in a windows-easy manner (point and click).