I have a coworker who was no longer work the same office. He has checked out files in VSS. How do I check in the item which checked out by him? Thanks.
Assuming that you can't just log on as him and check in the files.
One easy way would be to undo the checkout (you might have to use the admin tool for this) and then you checkout the files, copy over his changed files and check them in.
Actually, here's the MS support article about doing just this to solve your problem: How To Resolve Files Checked Out by an Unavailable User (for version 4, 5 and 6, but I'm fairly sure it'll be exactly the same if you've got a later version, there wasn't any real GUI changes as far as I remember).
Another thing you can do if the person has left or moved on is to delete their account with the admin tool and recreate it.
Then undo their checkouts (or check in, if you have access to their files) and delete their account again.
You can use "admin" to log in and undo the checkout.
Related
I have a branch of a large project with a couple of change packages on it. I would like to undo one of them. In Subversion, this task is trivial, esp with a tool such as tortoisesvn - select the revision(s) from the history and undo the changes. I cannot find a way to do this in MKS. I cannot even find a way to traverse my sandbox to an earlier revision. Can anyone please offer some guidance? I'd rather not have to create a second sandbox, diff the two trees and copy select changes from one to the other, which is what a colleague (who wanted to do the same thing) suggested.
Unfortunately, this functionality does not currently exist in Integrity.
Disclosure: I work for PTC Integrity Technical Support.
#mlizak_PTC
Do you then know somethig about
Change Package->Discard
Discard Change Package Entry...
Somehow the help to the change package functions did not enlighten me :)
#Jon
The only way I know to get the same as "traversing the sandbox to an earlier revision" is when you have a well defined checkpoint resp. project revision which you can retarget your sandbox to (build sandbox) and then resync.
You can then retarget your sandbox again to the state it was before (Mainline or a variant) and see the differences to the current state of the project.
If had to rely on changepackage info I would redirect the output
of the command 'si viewcp' to a file and try to sort that information out.
eg.
si viewcp --fields=configpath,creationdate,id,location,member,membertype,project,revision,sandbox,state,timestamp,type,user 132:1
From the gui you can also select all entries from a change package detail view and copy them to clipboard.
The problem i am trying to solve is where developers change files without going through the proper channels. The developer should be able to make the change himself but only after his work was approved, since the code is used in a lot of projects
I found this link that also describes my problem:
http://www.p4ideax.com/ideas/694/temporary-permissions
One way to do it is to have only the architects have access to the files and then granting the developer temporary access. Maybe the permission can be linked to a specific job in perforce. The only way i can see how to do that is by adding the files that the person should be able to change to a new field in the jobs template ( done by architect ). Then have a server app dynamically call p4 protect and manage the permissions table. Then when the job is closed the permission is revoked. The server app could be the bugtracker software.
Is there an easier way or even 3rd party software out there that can solve the problem?
I know that another way to solve it is to put these sensitive files in a branch and then only allow the architects permission to merge into this branch. This solution feels a bit heavy handed.
Any suggestions would be helpfull
This is something that could certainly be done with a pre-submit hook. There are examples at Perforce Depot.
My thinking would be to reject submits for files in that section of the depot that didn't have a job that was on the "approved list". You could create the approved list in a number of ways, although a simple one (if you're using Perforce globally) would be to put the job list into a file under repository control and then have that list be available only to the architects.
The pre-submit trigger would then basically need to:
- If the files being submitted aren't in the protected tree, let the submit happen
- Grab an r/o copy of the file from the depot
- Grab the job list from the submit
- grep the job against the list
- If the job is in the list, let the submit happen
- Reject the submit with an appropriate error message
I come from a Microsoft background in coding and thus have been used to Team Foundation Server and such for source control. Under TFS the files would check out by themselves in Eclipse and I would check them in when I was finished.
I have installed Subversion and the connector into Eclipse and have created my project with a local server
On Subversion do I have to check out the file when I need to change it? It doesnt change the RW permissions so I am not sure what the procedure is.
So basically if I am using Subversion in Eclipse what is the procedure for checking out a file and checking it in? What buttons are clicked?
Thanks for any help!
No, you don't need to "check out" to enable editing a file in Subversion. Subversion does not use the same type of locking VSS does (and TFS, by the sound of it - though I haven't used TFS myself). The locking that svn uses is sometimes called optimistic locking. Here is the svn manual page on file sharing and locking with a lot more specific details.
In Subversion, you would update your working copy like you normally would, but without any additional steps you could then just begin performing your changes to any file in the working copy without needing to lock out any other users, and commit when ready. If no one has modified it since you updated, then it will just commit the changes. Even if someone has, it will still commit (provided the same lines were not modified) and the server will handle it. If however, someone else modified the same lines of the file as you, then a conflict would occur and the commit would fail with "one or more files are in conflict". The conflict must then be manually looked at, eliminated, and marked as resolved, after which you would retry the commit and it would then go through (provided nothing else was in conflict).
Conflicts during every day work on a single branch are rare, which is why a lot of versioning systems use optimistic locking. Only when dealing with merging back and forth between branches do things sometimes get more involved.
Typically I would checkout the entire project, make my changes and then use the team sync view to review my code changes and commit from there. Right clicking is the key (see screenshots)
A great walk through on the basics can be viewed here.
Most of your actions will reside on under the Team menu; where you can commit, add, etc...
I use to use Subversion with eclipse. Now I use subversion with VSS. In both situations I've found I prefer, most of the time, to use Tortoise SVN for all my operations with the repository. Not as much of an answer but more of an opinion.
So my desktop is my primary workstation for VS2008 that's supported on the backend by TFS. I'm hitting the road for a week and I'd like to take a project with me. I'd like to checkout the entire project, copy it to my external HD and then work off that. I know that when I try to open it on my laptop that won't be connected to the network, I'll be asked to remove the source control bindings. So do I do that, and then when I come back to the office just copy all the files on top of my checked out version? I just don't wanna mess anything up. :)
You can take your TFS solution offline on your Desktop Machine. Then you copy the working directories onto your laptop (assuming your laptop has VS and everything else set up) it will allow you to continue working.
When you get back, you copy your Laptop solution root folder over your Desktop solution root folder, and then take the solution back online. Depending on the size of your solution, this might take some time, because it will do a file-by-file comparison to see what was changed (it will do this only against the files that you changed on the road, because your solution in an 'offline mode' will still keep track of which files were changed). Then a list will appear in your pending changes. You can check each of those (as you normally would) before checking them in.
You could use SvnBridge and get it out into a svn repository, and then do whatever you want with it because svn handles working offline really well, and then check it back in when you're done.
Since you have VS2008, this should mostly be handled for you. No need to make extraneous copies.
Here's a click-by-click walkthru of the new offline feature: http://teamfoundation.blogspot.com/2007/12/offline-and-back-again-in-vs2008.html
If you want to manually manage the offline state, Ben Ryan has several instructional posts: http://blogs.msdn.com/benryan/archive/2008/07/09/using-tfs-2008-power-tools-to-modify-server-s-offline-state.aspx
Checkout the entire project if you can.
Don't remove the source bindings
Before you check-in make a copy of your local source just to be safe.
What is the concept of each?
When is it ok to shelve your changes instead of checking in?
Shelved means the changes are set aside for you to work on later.
Checked in means that the changes are made available to the rest of the team, will be in the build and will eventually ship.
Very different. Think of shelving as a tool for context switching when you're not done with a task. Checking in means you're done (at least a part of it).
Shelve your changes when you want to save the changes that you have made, but need to go back to the previous version to make other changes (perhaps, bug fixes) that you want to deploy without the updates you are currently working on. Since you're usually checking in pretty regularly, I find this to be a rare occurence -- like I just deployed to the QA box and an error was immediately found. I'll shelve that day's changes bringing me back to the QA deployed version, make the update, then unshelve my changes -- merging the two as necessary. Any longer than that and you'll probably be looking to check out a previous version and branch instead. I'd be happy to hear of other experiences where shelving has proved more useful, though.
Other users can download your shelvesets by searching for them, so it is a good way to pass code around for reviews. however you will get an error if you try to unshelve code files that you already have checked out, so you need a clean environment ready.
I often shelve my changes at the end of the day if I'm working on something big that I can't check in. That way, if my PC dies overnight, I've got a backup on the server.
Darcy gets it spot on. You can also think of shelving as a private branch that is not publicly visible for the most part. Shelvesets can also be deleted completely, not like deleting checked in code. If you delete a shelfset it is gone forever.
Everyone above has said so much true and I learned allot from it.
Just to add my experience, correct me if I am wrong. In a project, we have a configuration file mypc.json specific to each PC of the developer. We usually override it when running server locally. Other team members have the same file name with different configurations in it. No one wants their file to be pushed with the same name to the development branch. So I use shelve to save these type of changes. Whenever I need these configurations I can easily apply changes from shelve and my environment configurations are back in my project.