I am wondering what happens in SVN when a file is updated directly instead of using SVN? The main reason I am asking is that there was a problem updating the SVN on my machine (windows) when the server (linux) had 2 names that were the same, but different case. I resolved this on the server, but didn't do it through SVN since it won't update correct, but I still get the issue. Do I need to run some kind of command to update it?
Thanks.
EDIT:
I deleted the comflicting file in the working direcotry and wanted to know if doing things directory in the working directory get tracked at all or what needs to be done to resync.
When SVN gets blocked because the repository is more "up to date" than the local checkout, one brain dead foolproof solution is:
Move (or remove) the files that are causing the conflict at the command line (don't use SVN tools to do this, and don't use the GUI if you have tortoise installed).
svn update the repository, which will restore the current copy of the files from the subversion server.
Decide what to do with your cached copies of the old files. Either manually merge them back into the repository, discard them, or remake the changes in the new svn managed files (depending on your needs).
Note that if you move the files into a directory using tortoise, make sure that you move it into a directory that's not associated with ANY SVN project. It's not fun trying to undo the helpful changes tortoise does in thinking your wanting a SVN move to accompany the file system move.
There is no need to run any special commands. If you updated the sources, the next time you will run svn update subversion will seamlessly merge the changes and you will get an uptodate working copy.
If you changed some files, they will appear modified or conflicted depending on the changes made by you and other users.
Related
So, to give some context. Recently i had to delete the whole project from my personal computer for some reasons. Now i want to download the whole project back onto my PC but don't know how. I assume that the clone button would do that (since that's what it does on Git) but seems to not be the case. I then tried to force update all the files thinking it would download the missing ones. It kinda works, i think but it takes awfully long. It took around 16 hours to update a folder that was about 20GB in size.
The project in question is a UE4 project, in case that's important
Now the question. How can i, most easily, download the whole project from perforce onto my PC? Thank you for your help in advance!
In the future, you can simplify this by using Perforce's "remove from workspace" or p4 sync #none command to delete the project from your PC. If you use Perforce's commands to clean up the workspace, it will:
not delete anything that isn't backed up to Perforce (i.e. files you didn't add to Perforce will be safe)
keep track of what you deleted (so the next time you do a normal "sync" it will just put it all back, without the force flag)
In the situation you found yourself in, an option apart from "force download" is the p4 clean command, which will reset your workspace's state to whatever you last synced to. Note that this will not necessarily preserve any local changes, but if you delete the entire workspace root this isn't a concern.
The time it takes to re-sync a folder is largely a function of your network speed to the Perforce server, but in some cases can be improved by parallelization (I believe P4V will do this automatically, and it's easy to enable via the command line, but if you're syncing via the UE4 plugin this may not be the case). https://community.perforce.com/s/article/9064
I'm moving my current server contents to a new one, and am currently in the process of setting up SVN. I'm fairly unfamiliar with SVN, typically using it to the extent of commits and updates.
I have two locations that I use SVN on the old server:
PROD location:
/var/www/html/new_dwutils/
and local:
/home/{user_name}/public_html/new_dwutils/
My interaction svn-wise is normally committing and updating at the /new_dwutils/ level.
Note: Running svn --version says I'm at version 1.6.11 for both servers.
I'm now trying to recreate this structure on the new server. My initial thought was to create the svn repo using something like:
svnadmin create /var/www/html/new_dwutils/
This creates the repo dir, but, when I copy my files into the dir, I am unable to do svn commands like status. However, when I go into a sub-dir of the copied data, I can use the svn commands.
This has me thinking that the repo is /new_dwutils/ and the copied data is considered a project? And the sub-dirs are working copies then?
Going off that thought, I deleted the repo, and made the html dir a repo:
svnadmin create /var/www/html/
I then copied my new_dwutils dir, and sure enough, I was able to do svn commands like I use too. What I've noticed is that when creating the repo, a few things are added that were not on the previous server: conf/, db/, format, hooks/, locks/, and README.txt. I get that these are svn files, but I'm not seeing the .svn file. I know that there was an update for svn that "removed" .svn files, but these files are now in /var/www/html/.
Now I want to setup my local working copy.
I've been doing (location /home/{user_name}/public_html/):
svn checkout file:///var/www/html/
Problem is it copies the html/ file, but nothing in it, and I don't want the html/ file I want the html/new_dwutils/ file.
I feel like I'm doing it wrong from the start, and would greatly appreciate some explanation on how to get on the right track. A step by step would be extremely useful, and if further clarification is need for files or directory paths, I would gladly detail.
Thanks!
The Subversion Manual will answer all of your questions.
If you're making a Subversion repository under /var/www.html, I'm assuming you're using Apache httpd as your server. Look at Chapter 6. If you already have a repo, create a dump file, then use that dump file to recreate the repo. Look at Chapter 5 on moving repositories.
If you don't know anything about Subversion, or are confused by the difference between the repository location directory and a working directory, read the on-line manual. It's one of the best pieces of documentation I've seen.
From description of your question it appears that '/var/www/html/new_dwutils/' is your working copy and not a repo.
Go to '/var/www/html/new_dwutils/' on the old server and type "svn info" this should give you location of the old repo. You should simply be able to 'svn co ' into the new location to checkout a copy of all your files from the old server (everything that is checked in - you will not get anything that is not checked in on the old server).
However, if your repo was local on the old server and you want to move it to your new server too. Then you can simply copy the entire folder to the new server and access it directly using its new location in 'svn co' command.
I have been going through documentation and such and have SVN working, but I want to put it on an existing directory. I imported that directory, so do I rename/delete the non SVN directory and then checkout the SVN to the non SVN directory location? I am just trying to understand how to get it to start posting to our website URL.
If so, is there any way to keep the current non SVN and make it SVN rather than import and overwrite?
Thanks, I am trying to understand SVN, but find a lot of the tutorials and such on the web to be confusing.
Yes, you have it exactly. Once your code has been added to the repository, you can get rid of or rename your original code directory. Then checkout the project from the repository into the same location as your previous code and continue working from there.
UPDATE
To make it so that your website is updated from the repository, you actually need two working directories, and a repository.
Repository: The repository stores the code and changesets, but isn't directly accessible as a file system. Keep a backup!.
Working directory 1: You develop and test your code from a working directory checked out from the repository. Commit changes back to the repository.
Working directory 2: Rename the code directory on your webserver. Checkout a copy of the code to your web server in its place. Technically it is now a working directory, since it contains the .svn metadata directories, though you won't usually make changes here.
Make changes to your code from your development working directory (1) and commit them back to the repository. When you are satisfied that they are working correctly and have been properly tested, on the web server's code copy (2) do svn update (or if you're using Tortoise SVN on the web server, do an update). This will synchronize the server code with the current development version.
Subversion will not automatically push updates to your web server. You will need to pull them in with an update when you need to. It is possible to use what's called a "post-commit hook" to cause Subversion to execute a script when commits are made, and that script could update or export code to your production web server. However, you would need to write the script and it's kind of an advanced usage of Subversion. I would recommend trying out the method I described with a working copy on the web server to get accustomed to the workflow befrore trying anything more complicated.
Addendum If you really want to do this (and I don't really recommend it unless you really test well) a very easy method would be to schedule a cron job that does svn update every couple of hours (or minutes) on your production site.
Don't forget that if you do happen to modify your code directly on the web server, you must commit it back to the repository from there, and do an update on your development working copy.
I want to add my project to a subversion repository. The project folder contains a symlink to a folder containing thousands of txt files that I don't need to add to the svn repository. I DO want the symlink-folder to show up when I checkout the code, however.
It looks like I can use svn addprop svn:ignore symlinked-folder to ignore the folder, but then I'll have to add that symlinked folder to every working copy I check out before everything will work.
Is there a proper way to do this?
Perhaps there is no way to deal with this, since a symlink is a filesystem artifact. Is there a better way to handle this situation?
CONCLUSION - EDIT
After all this investigation, I committed the symlink-folder by accident and SVN added it to the repository without adding any of the files within it. Upon checkout, everything works fine. The symlink-folder checked out and works.
I am using assembla to manage my SVN repository, so that might have something to do with this success.
The answers above are right, your symlink won't work if you check out the repository on windows.
But if you're aware of that and you don't care, you can add just the symlink without its contents:
svn add -N your-symlink
man svn add here
I believe you are correct, imagine if a user checked out your repo under Windows - how would SVN create the symlink when the underlying OS doesn't support it?
Is the target folder that you are symlinking to under version control? If so, you can make use of the svn-externals property.
You are right, it doesn't make sense to add a symlink to a repository. What would happen if someone checked out the source on a machine that didn't have access to the folder the symlink points to?
One way is to structure your repository so that you can check out the codebase without having to check out documents. E.g.:
Trunk
Tags
Branches
Documents
So you only check out the trunk or branch that you are working on, and when you require it you can check out the documents.
Alternatively, use a project management tool like Redmine to store your docs. It can integrate with svn as well so you can view your repository and manage permissions through it.
This has been plaguing me for a week.
SVN keeps telling me that a certain file "does not exist in repository".
Fine. Let's just delete it. Forget about it. Ignore it. Whatever. I don't really care about this file (especially if it continues to fail the nightly check-in).
The most bizarre part? A "restore" will actually RESTORE the file from the repository, so its there (corrupted, maybe?).
...and this has to be the icing on the cake. If I delete the file through Windows Explorer, SVN will RESTORE the file from the repository, and right after that state that it doesn't exist in the repository. WTF?
Does anyone have a clue how to get rid of this?
I've already tried clean-ups, reversions, deletions and anything else imaginable, but this one has me stumped.
Thanks for any tips you might have...
It seems most likely that you have corrupted your local working copy, e.g. by moving folders or some other manipulation that you did with windows explorer but should have done through the TortoiseSVN context menu. The information inside the .svn folders now no longer matches the state of the working copy, which is confusing Subversion.
To fix this, delete the parent folder ("Originals") in your working copy with windows explorer (NOT with TortoiseSVN). Then do a TortoiseSVN "update" at the root of your working copy. This should restore the folder in working order.
Another option is to discard your working copy entirely and do a fresh checkout.
Note that the next release of Subversion (1.7) will reduce the opportunities for corrupting your working copy by centralizing all metadata in a single .svn folder at the root.
I've had similar problems with corrupted working copies. Sometimes the working copies have a lot of pending changes but unable to checkin. To resolve this, I use the following approach (svn 1.7+):
Checkout a fresh working copy into a new directory (path2)
In the fresh working copy, if the offending file is there, delete it if needed.
Commit the fresh working copy
In the fresh working copy, delete everything except the .svn directory
Copy everything from the old working copy except the .svn directory into the fresh working copy.
Commit the fresh working copy again
Delete (or backup) the old working copy
Rename the fresh working to the old working copy (path2 to path)
I had faced a similar problem wherein i had a folder, for example "FolderA" which consistently shows in svn update even though I had deleted it.
It would not even show in the folder list but svn would still recognise it as if it exists.
I followed below steps:
1.Create same folder name for which svn was giving error in the same file location
2.Added it to svn checkout. Since it gave conflict errors, i resolved it using the svn option to resolve.
3.Deleted the folder and committed my svn.
Error was resolved