We need to monitor files in a share drive and check in file changes (new files or additions/deletions to existing files) to Team Foundation Server. Is it possible to map a TFS path to the shared drive and accomplish this ?
First,TFS is able to work with network/shared drivers. You could also create a workspace on the drive and mapped to TFS. You also be able to get latest and do some modification, then check in files.
So it's the same as monitoring files on a local drive and auto-check in to TFS. The most concern is the "auto-check in" operation, how would this be achieved. For example when you edit a file on the workspace in share drive, when would you check in files, after edit a character or a line, it's hard to judge when you finished the modification.
Actually if you are working on local workspace, your demand is by designed. When you had been modified externally VS or directly on files, TFS automatically checked them out without you having to do anything. The changes are added as a "pending change" status.
Lately you could check in the projects in the normal way and save the external modifications.
Certainly, you could also use tf command or TFS API to control the check-in operation.
To debug remotely with Delphi, now that the PAServer is normally used, one usually follows the following preliminary steps, as outlined on the online docwiki:
Create a remote profile inside your ide, in my case I'm calling it win7vm, this contains the IP address of the remote system, and a few options, and the PAServer connection password, but as far as I can see, it doesn't contain any context information like "I want to use the following remote folders".
The remote folders that are usually used to contain my target executable are usually a subdirectory underneath the scratch directory. If I configure the main scratch directory to be c:\scratch, and my remote profile was named win7vm and my project is name project1, then the IDE and PA Server are going to compile and deliver my executable to c:\scratch\win7vm\project1 and run it from there.
What I actually want is to have my executable be delivered to and run right in #c:\scratch#. I have a gigabyte of supporting files that all need to be in the same directory as my main executable and I don't want to have 8 copies of these supporting files. So, can this be done? Can I make PA Server NOT create a sub-folder with the name of my project and another for the name of my session? If so, is this done inside the paserver.config file, or on my client side, or somewhere else?
Update: I tried to change the Remote Path in the Project -> Deployment, but it does not work to use a relative path here. For example, change it to ..\..\ and the working directory in Project Options to ..\..\, but it still only delivers my executable to the folder c:\scratch\win7vm\project1 instead of directly into c:\scratch\
Update 2: It appears you can't do what I want, which is have the scratch directory be the main folder, and NOT create any sub-folders per-profile and per-project, and that if you don't like working in a scratch sub-folder, you should just set Absolute Remote Paths in Deployment and Absolute working folder in your project's Run options, and you should turn off restricted mode, however this means that the entire VM or machine you are remotely debugging can be manipulated by the PAServer, which is also hardly ideal. I believe that having a fixed root scratch folder would be a safer and more flexible way of working, so I'm leaving this question open, hoping to find an effective way to achieve a safe but flexible remote debugging technique.
Got the below in TFS and VS 2012 RC, anyone know of a fix? Doesn't seem to exist on MS website.
TF400018: The local version table for the local workspace
COMPUTERNAME;MYNAME could not be opened. The process cannot access the
file because it is being used by another process
Any suggestions welcomed.
We experienced this one as well. Migrating to the RTM makes this happen a lot less, but it can still happen a lot.
When using local workspaces (a new feaure in vs 2012) a local file based database is created to administer changes you make localy. When you change a source file, this file base database needs to be updated. If this update conflicts with the normal update task which routinely checks for changes you get this error. The cause of this issue is usually that you are using local workspace for more items than it was intended or that your disk I/O is too slow.
Workarounds for this are either:
Replace your disk with an ssd. Having better I/O makes this issue
happen a lot less.
Switch back to server based workspaces. (which handles this better)
Use the TFS-GIT connector and use git for offline support.
Split your workspace mapping in portions so they contain less items.
Please delete the files under %Temp% folder and open the project as
"Run as Administrator " mode .It works for me .
Regards,
Kamaraj
OK, I've been convinced that SVN is the way to go in a previous posting, but I haven't yet seen the epiphany. I'm not sure how I would set SubVersion up for my development environment.
Here's my current setup. I'm not keen to mess with it and it would be really nice if subversion could sit alongside it:
Work:
N:\Projects
N:\Projects\Lib
N:\Projects\App1
N:\Projects\App1\Help
N:\Projects\App1\Images
N:\Projects\App2
..etc
N: is on a separate server in the building.
There are several other development machines with the tools installed locally, but all development takes place referencing the files on the server - i.e. no source code is kept on the workstations.
Home
Laptop with same development toolset, and the sources in c:\Projects\App1.. etc, i.e. a mirror of the setup on n:\Projects at work.
The sources between N:\Projects and C:\Project are currently kept aligned with a custom app in conjunction with DropBox. File exclusions make sure that non-source files don't get sync'ed
I want to run SubVersion with this setup.
Where do I put the Repository?
Assuming I can have the repository in
a mutually accessible place, will SVN
remove the current need to sync
between work and home?
In order to embrace Subversion, you will replace your shared source directory with a Subversion repository that lives on the server. Each developer workstation will check out a copy of the whole source code locally (however, this could be a private area on a network server if you like).
You could retain your N:\Projects tree as a read-only copy of the daily build, or whatever. But one of the goals of Subversion is to mediate between two people editing the same file at roughly the same time. This is not compatible with a shared directory containing writable source code. Also, having multiple developers "share" the same Subversion working directory in some way is doomed to failure.
Why not create an internet accessible (free) trial Subversion account, and play around a bit, to get yourself familiar, before you move your entire source code tree into it. Just so you don't delete everything you own, by accident. Maybe start with one dummy project. Host something on the internet. Without even paying a cent, you could use this site:
http://www.projectlocker.com/
Then you can set up your very own starter subversion server. You can create a brand new Delphi application (file -> new delphi application), and add a button, and double click that button, and write a message box thingy, or whatever it is you like to do in demo apps. Now create a subversion repository (perhaps they call them projects, up on project locker), and add the folders you saved this project into, to that repository.
Now you can play with (a) tortoise SVN, (b) the SVN integration build into Rad Studio XE, if you have Rad Studio XE, and (c) the version control plugins that come in the JCL, if you don't have Rad Studio XE.
Also, may I suggest that if you want to have any hope of knowing what you're doing you learn how to add and commit, and update, from the command line. It's really not that hard. And it will pay off later.
Knowing you can type svn co http://reposite.something.com/svn/myproject to check out a project to your disk, is very handy. Sometimes, I think GUIs are training wheels for your brain. You cripple yourself if you don't learn command lines.
A benefit to a hosted subversion service like the one I showed above, is that you have an offsite backup. Of course, such hosting is always free even for large projects, if you are writing something open source. Then you can host on sourceforge. Otherwise, you're going to (a) need to use your own internet accessible host or (b) pay for hosting, otherwise you're not going to be able to easily access your repository at home, and at work.
Personally, if it was my own business, or my professional job to write software, I would host my own subversion server, and it would be private (LAN) only, and I would use a VPN to access it from home.
1: You definitely want a repository accessible from both locations. Either that, you you will need to use a distributed versioning system, like Mercurial or Git
2: Yes, there will be no more need for your custom sync app. This is exactly the job for your versioning system. Syncing manually in addition to using SVN is not necessary and would even create lots of conflicts.
Your shared directory should be removed and a copy of the code present on each machine that is a working copy of the SVN repository.
Use your server with the files to place the SVN server on it or any server that all including your home computer have access to.
Commit / Update every day, multiple time a day and manage merges if needed .
For the home access the simplest is to either get a dedicated server on the net or redirect the correct port on your router (but you will obviously need some access control in place) so that your repository is accessible from outside. If needed you could limit access from your home IP or from a list of IPs with a good router.
The other solution as other said is another kind of version system called "distributed" where every commit is done locally in your own repository on your own PC and this repository is merged on the "main" repository to share code and the change of other members of the team are pulled back in your local repository (You don't need any "main" repository technically on a DVCS but for a company that's what you will have).
See Git or Mercurial for good DVCS (Git syntax sucks but it's the most widely used system and technically the best one).
Put the repository in the safest place. That usually means a good redundant server (disks, etc.), in a controlled server room, and one which is properly backed up. When you switch to a VCS, source code to work on is typically in local machines sandboxes, because each developer must have its own. Then changes are get and sent to/from the server. Be aware that some tools may have issue is on a remote directory, because of the way for example the SMB protocol works - check they are supported explicitly if you need to use them. Unless you have paramount security needs, IMHO working in local sanboxes is faster and easier.
If you can access the SVN server from home (i.e. via a VPN), it will be not different than working from the office. You will "sync" (update/commit) your laptop sandbox the same way, you don't need a local server and repository. If you need a local server (reason could be you can't access the central repository from outside, need to work disconnected yet version files, etc.) there could be ways to replicate across SVN servers, but at that point maybe a distributed VCS should work better in such scenario.
Using LMDWebHTTPGet1 from LMD Innovative downloads the file to the Temporary Internet Files directory only I would like to get it into a directory of my choice
TLMDWebHTTPGet uses the same underlying infrastructure that for instance Internet Explorer and Google Chrome use (adding benefits of for instance sharing proxy settings).
I don't think you can redirect that layer to your own download folder.
So do the same as Internet Explorer does:
download it to the "Temporary Internet Files" directory,
copy it to the final location,
remove the temporary file.
--jeroen