tortoise svn delete local file - tortoisesvn

i am new to tortoise svn, and im working on a group project. the main files are located on a separate server. how can i delete any working folders on my machine without affecting the files on the server?

Deleting your local working folders would never delete the files in svn server unless you do an svn commit to the server. So you can safely delete the working folders on your machine

You can delete the folders/files on your machine - as long as you don't tell SVN the server will never know. Which means - just don't Commit and you should be fine.
When i'm learning an new source control system, i usually will zip the local directory before i delete ... just incase i screw up. Then after i'm sure i didn't screw up I stop doing the zips.

Related

Unable to remove tortoise svn link from a drive. Mistakenly checked-out the whole drive instead of a specific folder

I gave D: drive as my local repository while checking out instead of giving a folder.
I.e unknowingly, I gave the url path as D: drive for svn check out. Now all the folders inside my drive have been added to the svn repository. And the drive is now fully in svn control. How to rectify this problem?
I tried exporting the folders inside the drive to remove the link. And I tried to delete the folders. But the problem prevails still.
To unlink your drive from subversion, delete .svn folder from it.
I suppose you have not committed your changes on SVN server. If you have, then delete from there too.

How to the history of files changed on a Rsync server

How can I instruct RSYNC server to keep a copy of the old versions of the files that were updated?
Background info:
I have a simple RSYNC server running on Linux which I am using as a backup of a large file system (many TB). Let's call it the backup server.
On the source server, we run daily:
$ rsync -avzc /local/folder user#backup_server::remote_folder
In theory, no files should be changed on the source server, we should only receive new files. But, nonetheless, it might be possible that some updates are legit (very very seldom). If rsync detects the change, it overwrites the old version of file on the backup server with the new one. Now, here is the problem: if the change was a mistake, I lose the data and do not have the ability to recover it.
Ideally, I'd like that rsync server keeps a backup of the replaced files. Is there a way to configure that?
My backups are local to the same machine (but different drive on a mount point of /backup/)
I use --backup-dir=/backup/backups-`date +%F`/ but then it starts nesting the things rather than having a load of backups-yyyy-mm-dd/ in the /backup/ folder.
If someone has a similar issue, there is a easy solution:
Execute a simple cron that changes access rights in the destination computer.

Update / download the actual file from the SVN

I had an emergency change something in the file without going through committing to SVN. That is, instead of to the local computer to make changes and commit the this, I immediately changed the file on the server (for that was the reason).
Tell me, how can I download a file from a server on a computer?
If your server's space is Working Copy and your local workplace is Working Copy (and both WCs are binded to the same Repo-URL) you can commit from server & update from local
If your server isn't WC, you have more headache around syncing diverged changes

How to do version control via ftp?

I have a web dev. client using a shared host that doesn't allow shell access, and thus no access to SVN, Git, etc. I've tried to convince him to move to one of the many cheap options that allow it, but he won't do it. If I use version control on my staging server, are there any tools that will allow me to replicate the changes to production via ftp? Locally I have both mac & windows, the staging server is linux, so something that works on any of those platforms....
Using your Linux staging server you could keep a separate checked out copy that you use specifically for that host and then use a utility to mirror that directory with the host server.
LFTP is useful for this kind of thing. Its available for most Linux distributions and includes a 'mirror' function:
Mirror specified source directory to
local target directory. If target
directory ends with a slash, the source base name is appended to
target
directory name. Source and/or target can be URLs pointing to
directories.
Some kind of ftp mirror software is what you need. Not tested it but a quick search gave me this Java application. You could run that over your up-to-date checked out repository.
Good thing for keeping SVN repo and FTP copy in sync is svn2web. May I suggest creating separate branch for production copy and do merges to that branch for uploading to production server.
You probably need to write a batch file that is able to
Export the SVN repository
Upload the exported files to your Linux server via FTP
Short of finding / implementing some FUSE based CoW file system that supports immutable versions .. I'd just find another (more developer friendly) host. As far as I know, no FTP server supports this natively, nor can I think of any elegant means of putting it in place with script hackery.
I could be wrong.
This question (and answer) really helped me just now as I implemented version control via gitolite on a separate server and lftp.
Here’s what I did:
Set up gitolite on my ubuntu staging server
created base repo (i.e. foo.git) on staging server
cloned foo.git into working directory on staging server
cloned foo.git into working directory on local development machine
Developed locally
Pushed changes to foo.git repo on staging server
On staging server, logged into working directory, and pulled in changes from foo.git
lftp-ed into shared host (like you mention above)
Once in shared host, ran:
mirror -R --only-newer --delete --parallel=10 /source/directory/ /target/directory
Notes on the mirror command options:
-R - this pushes the source/directory to the target/directory. (mirror pulls in from target to source without this, think reverse)
—only-newer - without this option, even if you only changed one file, the mirror command will send all the files in the source directory over to the target directory. with this option only the changed (newer) files are transferred over the wire.
—delete - deletes files that are no longer in the source directory but still in the target directory. one of my pushes involved deleting expired assets. without this option, the same files would have stayed put on my shared host after executing the mirror command.
—parallel=10 - transfers 10 files at once (instead of 1 by default). this made the process much faster
While this is what worked for me, I’m sure there are ways to improve on this. I was grateful for this question and thought i’d share my experience.
Rsync will do this over an FTP connection. You probably already have it installed if you’re on a Unix-like system.

Cruisecontrol, deployment, folder permissions

We're using cruisecontrol.net, it builds the version, creates a zip file, then 15 min later, unzips the file on the Integration server. But when the folder gets to the integration server, often, the security permission on one of the folders is totally hosed. The Domain admin and folder owner can't even open the folder in explorer. We reboot and the folder permissions are good we can delete the folder and redeploy the zip file and it's okay.
Does anyone have any idea what or how the folder permissions are getting so messed up?
Any tools to use to diagnose/watch what exactly is messing it up?
Have you tried using psexec from system internals to upzip to file on the remote machine rather than the build machine?
Also, it seems to me that rather than unzipping the zip just copy the stuff directly to the remote server. I'm not seeing the reason to zip it and then just unzip it?

Resources