in my project I have configuration files separately in SVN. The needs to stay on the server, so I have an SVN checkout job that run before any deploy.
If I want to deploy on my server a previous version how can I overwrite all the configuration files without having merge problem? (e.g. version 2.3 is currently on server, I need to deploy version 2.2 with a patch, and consequently update all the configuration files at version 2.2)
Basicly I want to replace an entire branch with another, avoiding any conflict.
I can use rm -rf (unix server), but is a bit risky.
You can use SVN switch using this command - svn switch branch-2.3 branch-2.2
For this you need to have these per-equites -
Branch should be cleaned up, no .svn temp files should come in picture
Any of the local changes may go away.! So make sure that, you have everything committed.
So you can handle these things easily using commands and perform the job.! Hope this help.
Related
How to integrate a branch back to trunk when files in the trunk have been moved or renamed while files in the branch have been changed?
The question Integrating moved files in perforce explains similar issue in reverse order, i.e. integrating trunk into branch where files have been moved. However, the answer does not help.
I am unable to use p4 integrate -3 in my scenario, and perforce always asks to specify -D or -Dt flag, which if specified, always creates new files instead of merging them into the existing moved files. Note that I am using latest Perforce client 2014.1.
If at all possible I'd recommend upgrading your server; I'm inferring from the fact that you're unable to use "p4 integrate -3" that you're on a fairly old release. With the latest server release the "integrate -3" functionality is enabled by default, without having to use an extra flag or anything, per this blog post:
http://www.perforce.com/blog/130806/quality-life-improvements-renamed-files
Having this functionality is a pretty big deal since it makes the scenario you describe "just work" -- all you have to do is integrate and resolve as normal.
Without that functionality, you have to do some work -- either modify a branchspec to line the current versions of the files up and use that to integrate the content, or manually recreate the same rename operations in the branch so that the files line up normally.
Note that this functionality requires a new server in addition to a new client, so a 2014.1 client on its own (with an old server) won't do the trick -- a server upgrade is necessary. If you're on an old release you'll need to do a restore from checkpoint as part of the upgrade, per the instructions in the administrator's guide:
http://www.perforce.com/perforce/doc.current/manuals/p4sag/chapter.install.html#d0e1167
but I would recommend you don't let that deter you; you'll be getting a lot of improvements. :)
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 am facing a problem with TortoiseSVN (my client version is 1.6.16 and the SVNversion is 1.4.6.28521).
The projectA project has the classical architecture, with three folder: trunk, branches and tags.
I have rights to Read and Write from a projectA folders (tags,branches and trunk).
While working in the trunk, there is no issue, everything works fine. The only problem is that when a release time comes (or branching time comes), and I want to create a tag (a branch), I want to use the TortoiseSVN dialog "branch/tag". Then I choose the origin from the trunk or the revision o nthe trunk i need, and choose the "To URL" like "http://..../projectA/tags/v2.0".
After clicking "OK", it will let me know that the access to "http://...../projectA/" is forbidden.
The only solution right now, is to checkout the "projectA/tags" folder to a local folder. Then in this "projectA/tags" folder I will create one new folder with the name of the tag I want to create, and I am able to commit it without any problem.
I don't want to manually create the folder of the tag/branch like this, andwould rather like to use the "branch/tag" feature of TortoiseSVN.
Anyone has an idea about this issue ?
There is a recommendation in Subversion (at least on Windows with TortoiseSVN) to use the same major version as the server. You are allowed to ignore that recommendation, and most of the time, it does not hurt, but here you may have a case where it makes a difference. You should at least check if
the server could be upgraded to 1.6.x XOR
the client (your installation) could be downgraded to 1.4.x
However, your client will ( in the second case ) no longer work with your checkout directories. Branching has changed a lot from version 1.4.x to 1.6.x, so you will face a hard time if you have to use a 1.6.x client with a 1.4.x server.
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.
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.