Can someone please explain, in layman's terms, the difference between a file 'Check Out' and a file 'Hijack' in Rapid Application Developer IDE?
Both should reference a file in a ClearCase snapshot view used with ClearCase SCM Adapter that is included in Rational Application Developer and the optionally installable ClearCase Remote Client Extension:
checkedout: ready to be modified (and no-one else can check-in the same file before that checked out file is checked-in, in case of a reserved checkout)
hijacked: the file is not checked out, and yet it is made writable (through OS: chmod or Windows file properties)
An hijacked file needs:
either to be checked out (to keep the local modification) and then checked in,
or canceled (the local modification are lost, and the file is read-only again)
Related
I often download file from vscode remote server, but how could I change default download folder? It always opens a specific folder I don't want to download into.
I don't know about configuring the detault download directory, but there was an issue created and resolved to get VS Code to Remember target directory when downloading files #140358, which was implemented in commit ca936dc.
bpasero (one of the VS Code maintainers) commented to close that issue as resolved:
For the "Download" command we now remember the path where to download and restore that. This information is stored globally (i.e. applies to all windows) but will not roam via settings sync, because paths are typically machine local.
Previously we did a questionable computation of a default path that typically always ended up in the user home directory, which imho does not make a lot of sense for the download operation.
Verification:
connect desktop to any remote
right click from the explorer "Download"
pick a destination
repeat and verify the destination restores even across restarts
In eclipse, you can right click in a file and then select Team / Show local history. This shows your local saves and is pretty useful.
Now, I made some changes to a file. I am 100% certain I made them. But they have disappeared. Overwritten by someone else I guess. But when I check my local history I can't see my file changes.
My question is:
Does Eclipse always update the local file history for every save? How reliable is it?
Note: I appreciate people are thinking how can someone else overwrite your files. I am working in a force.com project. When you make changes to a file they are push to a central server. There is source control per se. It is like everyone working with a shared folder.
It depends. Each Eclipse plugin dealing with workspace artifacts can optionally set a flag for local history in its API calls to the workspace resource management when deleting or changing files. If the flag is set, changed files surely get copied into local history. But every plugin can set this flag different.
So even if you might have an editor plugin which always uses local history when saving the edited file, another plugin might delete/modify the file without using local history and therefore interfere.
Summary: Local history is not a reliable way to go back to previously saved versions of a file.
If anyone else runs into this issue, check to make sure you didn't accidentally edit a file in a build or target directory. For instance if you are working on a jsp page and make edits, swear you changed it but they are no longer there in the editor or the local history when you open the file, check to make sure you weren't editing the built version by accident.
This sometimes happens if you are quick to use ctrl-shift-R shortcut to open resources. To avoid this, you can set your build or target folder to derived by right clicking on the folder and checking the derived checkbox. This will prevent the resource from showing in the Open Resource view which could save you headaches later.
To get the code back, I opened the target version and used undo to get to the edited version.
When I started my current job, I was told to install the Subversive plugin for Eclipse, and given the URL of the repository to pull projects down from. My username and password were/are the same as my Active Directory credentials. So I installed the plugin, created a new repository (don't remember how, but it was easy to do), and have never looked back.
I am now being transitioned to a different team, who also use SVN for source control, but have it set up on a completely different server. I was asked to put in a ticket with the systems people to request access to this SVN server so I could access this other team's code.
The systems person assigned to my ticket just sent me the following email:
Attached are the pkcs12 files that are needed for your access to SVN on [svn.someserver.com]. You’ll need to put these files on your local systems and then add the following configuration to the ~/.subversion/servers file, for your SVN client. I just use the svn command on linux, so my home directory contains the .subversion directory and the servers file is in that directory. I will send your password separately.
Note: I have a Windows machine, so a part of my confusion may stem from the fact that the tech is on Linux and I am on Windows 7.
The attachment was a ZIP file that extracted two separate files:
foo.pem - a PEM file (?)
atannon - a "Personal Information Exchange" file (?); same as my username
The tech followed up with an email giving me my password in cleartext.
I checked my home directory and do not see a .subversion or .svn hidden directory anywhere. I am wondering if I need to follow his directions, but using my Program Files/eclipse/ directory instead.
So I have several questions here, all relating to how to configure SVN access in the manner prescribed by this systems tech:
Why was it so easy for me to get set up with the first SVN server when I started my job (just install the plugin and find the repo through Eclipse's Repo Explorer), and why does this server require so much configuration? I assume there are multiple methods for gaining access to a SVN server, and this 2nd team just uses a more lengthy setup method?
Can someone give me a super-quick rundown of what each of these files are and what purpose they serve? And why I need to install them locally on my system?
Where should I install these files? The tech wanted me to put them in my ~/.subversion directory, but I never created one because they only SVN client I ever installed was Subversive (through Eclipse)
I tried creating a new repository for [svn.someserver.com] in Eclipse. I supplied my username and the cleartext password the tech sent me and now it is giving me a dialog stating I need to "Provide authentication information", asking for SSL settings, and specifically a File and a Passphrase for the Client Certificate...would the files he sent me suffice for this? If so, perhaps the answer to my question above just requires knowing which files to point Eclipse to, and I don't have to install these files anywhere
I usually don't like to ask multiple questions inside of one giant question, but these are all so similatrly in nature, I didn't want to clutter SO with too many closely-related questionss.
Thanks in advance for any help here!
Why was it so easy for me to get set up with the first SVN server when I started my job (just install the plugin and find the repo through Eclipse's Repo Explorer), and why does this server require so much configuration?
First server have less paranoid (if have any at all) security settings, second was configured by Real Admin. Client-certificate authorization is most bullet-proof method
Can someone give me a super-quick rundown of what each of these files
are and what purpose they serve? And why I need to install them
locally on my system?
foo.pem is your Personal S/MIME certificate, which used for client authentication, which you have storelocally and link with repo's server. atannon (I think) contain password for certificate privatekey, which will be asked (TBT) at first operation with repo (or with all, if you don't cache password)
Where should I install these files? The tech wanted me to put them in my ~/.subversion directory
For Windows, $HOME-dir (~ in Tux-world) is C:\Users\<Your Username>\ (Win7) or c:\Documents and Settings\<Your Username>\ (WinXP). You have to find inside this tree servers file (and remember it's location for future). In case of my XP (with TortoiseSVN only, no any Eclipse)
Directory of c:\Documents and Settings\Badger\Application Data\Subversion
30.06.2010 09:02 <DIR> auth
02.01.2012 19:11 6 712 config
30.06.2010 09:02 4 400 README.txt
30.06.2010 09:02 7 832 servers
"Provide authentication information", asking for SSL settings, and specifically a File and a Passphrase for the Client Certificate...would the files he sent me suffice for this?
Yes, pem-file is certificate in PKCS12-format, atannon (I hope) - contain password for it
Is it common for a developer to keep their NAnt global configuration file (NAnt.exe.config) in version control?
And should or shouldn't the the rest of the files in the NAnt installation be added to the ignore file of the version control system?
One use of version control is as a backup. If the only copy of NAnt.exe.config is on a hard disk that dies, it will take some effort to reconstruct it (along with everything else that disappeared and wasn't backed up).
From the corporate perspective, having all of the work in progress backed up is a method for preserving assets. The corporate owner of the source code asset is assured that the asset will not be destroyed.
When there is another backup strategy, then sometimes the rule of thumb is not to put anything into version control that should not be shared with other developers. Such as customized data relevant only to one user and/or machine, or confidential information.
I keep a copy of the NAnt code for the version I'm using. This includes the .config file. This is so my build system is safe from "it disappeared from the internet" events (unlikely, but still).
Beyond that I see no reason to keep it around on your code repository, unless for some reason you've modified it somehow. Most everything in NAnt can be overridden in build files, like the target framework and so on.
Is it possible to keep the attributes of a version controlled file unchanged? I have a directory structure which I'd like my installer to recreate on the client machine. I was hoping the entire directory could be placed on VCS without affecting the file attributes.
I'm using TFS but would also like to hear about other version control systems.
Edit: I'm talking about Windows file system attributes such as Hidden/Archive/System/Read-only but any other information such as creation/modification dates is also welcome. I have a directory structure in which some files are read-only and need to have those files installed as such on the client's machine. TFS tends to set/unset the read-only attribute depending on whether the file is checked-in or checked-out.
TFS does not store the file attribute data (such as created date, modified date) etc in the current versions of TFS. The values for those attributes will be the time on the local computer when the files is first downloaded / modifed.
TFS 2010 has the ability to attach arbitrary metadata to version control objects. You'd have to write your own tool, however.
API specification (prelease): http://blogs.msdn.com/mrod/archive/2008/05/09/team-foundation-server-properties.aspx
Usually version control systems do not store full metadata information about the files under its control in repository. In usual usage of version control systems this is not needed, and might have even cause problems; version control systems store "sane" subset of metadata (like e.g. executable permissions, and symbolic links).
Possible solution is to use hooks to save required parts of file metadata on commit to some file (usually plain text file), keep this file under version control to distribute it automatically to all clients, and use hooks to restore metadata on checkout.
Example solutions of tools to save and restore metadata include (unfortunately examples are for Git, and not TFS, but it is the idea that matters):
metastore
git-cache-meta
Example solutions of tools to keep configuration files under version control (again: all of them using Git as a backend) include:
IsiSetup
etckeeper
giterback