I recently started working with SVN, I am using it in combination with Wordpress.
I just made a number of updates to Wordpress and to some plugins, and I would like to know in what order I need to update, or whether it even matters.
Here is what I did:
Locally on my computer:
svn delete folder xyz
commit the deletion
add a new folder by the same name
svn add the folder
svn commit
Now if I log in to our development server, do I just to "svn update" ?
Or do I need to go through the various versions by updating to specific version numbers?
The reason I ask, is because I have had one or two tree conflicts in the past where I got:
Tree conflict (local dir unversioned, incoming dir add upon update) for location wp-content/plugins/ExamplePlugin/ExampleSubDir
Does my workflow lead to such errors? Am I overlooking something?
Your workflow is fine, and yes, you would just perform a single svn update on the other computer to get fully up-to-date.
The workflow you describe would produce a tree conflict if you happened to have an unversioned folder named "xyz" in the same location as the one you just committed (which is what the error says in the parenthetical remark). You should remove that unversioned folder and then let SVN add that folder itself (via the call to update).
If you haven't already, it might be worth reviewing some of the documentation to ensure you understand the fundamentals.
Related
Periodically we receive announcements of new maintenance builds of Oxygen XML Editor. It's easy to locate documentation on installing new versions, but I was unable to find any instructions on installing maintenance builds.
In the past I've renamed the downloaded folder, e.g, "17-1", which completely duplicates all the files in Applications (I'm using OS X), then later on deleted the older folders when it seemed safe to do so.
I would like to know the best-practice, most efficient way to routinely install these frequently released maintenance builds.
Since there is no Oxygen installer for OS X (it's just an archive), there is no straightforward way of upgrading (installing in the same folder), like there is for Windows or Linux.
The official upgrade procedure for maintenance builds (it's the same for minor version updates) goes like this:
To upgrade:
For Windows and Linux you can install the new build in the same folder as the previous installation, it will automatically upgrade it.
Before you upgrade, if you have added files or made changes to any of the files from the Oxygen installation folder (especially the frameworks folder), you may want to create a backup of them because they will be overwritten during the upgrade procedure. Custom frameworks will be preserved but we recommend backing them up anyway, just to be safe.
For Mac OS X you will have to either move the old folder from Applications to a different location and put the new version of Oxygen in its place, or install in a different folder. You can then copy any files you may have changed from the old folder (if any) to the new folder.
The Oxygen preferences will be preserved since they are located elsewhere (user home folder).
What I'd like to add is that, if you have custom frameworks and want to keep Oxygen up to date, it's a good idea to keep the custom frameworks in a different folder (from your user home) than the Oxygen installation folder and simply configure Oxygen to load them from that folder (Options > Preferences, Document Type Association > Locations, Additional frameworks directories). This greatly simplifies the upgrade procedure.
Regards,
Adrian
According to a colleague, his way of doing it, FWIW:
I keep all oXygen stuff in the directory /Applications/oxygen
When I get a new oxygen.zip download, I put it there, unzip it, and rename the directory to the oXygen version name. So right now I have
/Applications/oxygen/17.0
I usually compress the previous version and delete the directory for it, but keep the zipfile for a while in case I need to revert to the
old version
I keep the related jarfiles in /Applications/oxygen/lib so that they don't live in the same directory as an oxygen version that might get
upgraded
I create an alias under /Applications named "oxygen" that points to whatever current version of oXygen Editor I'm using (and it needs to
be updated whenever the current directory changes)
I can't accept this as the best answer unless I receive confirmation that this is the ideal method on Mac OS X. If there is another proposed procedure that is conventionally accepted as the best practice, or a definitive answer from an authoritative source, then I will accept that answer.
I have a conflict and I am unsure how to resolve it.
The error I get when doing svn udpate is:
Tree conflict on 'wp-content/plugins/eventON'
> local dir replace, incoming dir edit upon update
Select: (mc) keep affected local moves,
(r) mark resolved (breaks moves), (p) postpone,
(q) quit resolution, (h) help:
I do not understand what this is trying to tell me.
I would like it to replace the local version of the web server's plugins/eventON with the version that is in the SVN repo.
Background info:
The error message may be the result of deleting the folder that was being versioned through Wordpress admin panel, and then copying another one in the same location (a bad attempt at updating a plugin while forgetting how SVN works).
I guess that running the update through Wordpress deleted the .svn folders that were present in the plugin (the needed stuff for SVN to work properly).
So you could delete the new, unversioned eventON folder that you have copied in your repo, and run a svn update from one directory above (wp-content/plugins), in order to retrieve the old, versioned plugin.
If it does not work, it may be easier to delete the repository and checkout a fresh version...
Then, you will be able to update your plugin manually through SVN, and commit it.
As long as you already know that you want the server's version and not the local, this shouldn't be too difficult to resolve.
Identify which files are conflicted with svn status.
Since you want to keep the repository's version, you probably want to remove any conflicted files that svn has added from your working copy. They will have an A next to them in the output of svn status. In your case you should probably back them up first, since svn can't get them back for you since they're not in the repo yet. Now use svn delete --force my/fileToDelete. You don't need to delete anything not related to the tree conflict if you have made other changes you want to keep.
Run svn resolve --accept=working my/treeConflictFolder on the remaining folder that is conflicted (it will have a capital C next to it in the output of svn status)
The tree conflict should now be resolved, so you should be able to commit and update normally.
Further reading: http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html
recently, i upgraded to Flex Hero 4.5 and created a new workspace. Then, i imported a project from the former workspace and started working. when i tried to upload the project from the new workspace to codereview, i got the error message: could not guess version control system. Are you in a working copy directory? How does one resolve this issue?
thanks
I have read somewhere that i need to checkout my svn but i thought that you only checkout when you want to get a folder/file from the svn.
Sounds like you've got a bit of a mess unfortunately. Hopefully you're not in the habit of doing a ton of changes without checking in. I would suggest you:
Back up your latest changes to a safe location
Check out the project from SVN into your new workspace (which is what you should have done initially) - creating a brand new project folder
Merge the changes you've made into the now-correctly-versioned copy of your project (you could do this by just copying files from the "latest"/project backup folder overwriting the SVN versioned files, but if you do--do NOT overwrite any .svn folders). You could also use a tool such as WinMerge or WinDiff to find differences between the two projects (of course ignoring .svn folders).
If you have a small number of changes it shouldn't be bad, but if there's a lot, you might want to follow SolarBear's branch suggestion, if WinMerge isn't going to cut it.
If I understand correctly your latest comment, you did a svn export on your code. The export command, as the doc mentions, creates a "clean" directory tree, i.e. without the .svn directory. So basically, these are files not controlled by SVN; also, you lose all the history of your files. The best way would have been, I think, to do a checkout in your new workspace and then work from there. It could take some time, but it's much easier to manage afterwards.
One possible way to make this work would be to checkout a clean copy your code somewhere safe and then merge your changes into this clean copy. However, if your trunk or branch changed a lot in the meantime, this could be very, very tedious. I could then suggest to branch your trunk, checkout that new branch, slowly merge your changes into that branch and when you're done and everything's working OK, merge the branch back into the trunk.
This may be best as a wiki, given comments on here:
Share common / useful SVN pre-commit hooks
I'm using Visual SVN 2.1.7 on a Windows 7 machine. We have developers committing from various countries and we can manage the code changes by running local copies of the changes and then uploading manually via ftp to the server for each website that's being worked on.
This is an incredibly time consuming process, but less time-consuming than fixing bugs on live sites, so it's a step in the right direction.
On the Visual SVN website it makes a mention of post-commit and pre-commit hooks but fails to show where that can be accessed, even though it mentions there is a GUI. There's no sign of a GUI or even an option in the installed version, so I can't locate, firstly, where to access it.
Assuming it can be done via scripting, I have googled and come to SO to look for some guidance on where it might be and how it might be done, but it seems to be a lot more complicated than I'd hoped.
Does anyone have any experience or guidance, including sample scripts, for how to perform the following tasks on Windows (without perl installed)?
a) Create a pre-commit command/file and attach its execution to a repository/commits to it
b) Create a post-commit command/file and attach its execution to a repository/commits to it
and in my case, one specific task:
c) How to have a local Visual SVN installation on a PC that can send committed files to remote CentOS shared hosted server (not VPS/Dedi or Cloud hosted and SVN can't be installed on those machines)
It's a great piece of software but it seems like the barrier is quite high to being efficient with it because it's unclear what questions you need to ask or where to look. Hopefully, you can help provide a better starting point for those stuck in the same way.
Thanks :)
Access to hooks:
1.Start VisualSVN Server Manager
2.Open Properties for your repository
3.Select Hooks tab
4.Edit the needed hook
Hooks are convention rather than configuration based. You don't have to "hook" them up. Create a pre-commit hook and you have a hook running before commits. Create a post-commit hook and you have a hook that runs after a commit.
Here are the steps you can do in your post-commit script for what you need:
You get the repo path and revision commited as arguments to the post-commit hook, so use something like repo=%1 and rev=%2 to get these values.
One way to copy files after commit would be to have a working copy on your server, issue an svn update on this working copy after your commit in your post-commit hook and then copy over the files. You can selectively copy over files by getting the files that changed using svnlook changed. svnlook needs a revision and use the rev variable that you set earlier.
The script itself can be in any language.
I am experimenting with using subversion to deploy updates to my ASP.Net application, one issue that I am facing is that whenever the working copy(containing the build) is updated the ".svn" folder inside of bin gets updated and this causes the ASP.Net appdomain to recycle. I don't want this to happen unless something in bin has actually changed.
Is there a way to tell ASP.Net to ignore the ".svn" folder inside of bin? Basically not watch that folder for changes?
If this does not work out, I'll be using a staging folder outside the web folders to download the builds onto the servers and then use scripts to patch/update the actual web folders.
[Edit:] The svn export option will not keep my deployment under version control, I want to be able to do "svn update" on the web folders to deploy and rollback releases.
If you use svn export instead of svn checkout to get the files from your repository you will not get the .svn folder on your server.
[Edit] Another option would be to delete "bin" from your repository (and possibly commit it to another one, if you need revisions), and then just copy the bin-catalog to your webroot manually when it changes. Remember to add "bin" to your svn-ignore-list.
You probably want to add the "Bin" directory to your svn:ignore list; it should not be committed anyway as it contains compiled code, not source code.
In any case as your final deployment "svn export" is probably a better choice, as others have noted.
Have you thought about using a Continuous Integration server?
Continuous Integration basically refers to a development practice designed to increase the frequency of commits to the repository.
The more often you commit the better granularity you have over rollbacks and also the less that can be broken between commits.
The tools listed below all work with subversion and can be combined with MSBuild on the server to produce an automated build & deployment system.
MSBuild directives include the option to ignore certain files (i.e. code behind) when copying to live directory. In addition, some files you may want to have a development version and a live version... in this case we should write a "transform" script for MSBuild which just makes sure that the file is correct for the live server when copying live. (i.e. web.config)
Hudson - http://java.net/projects/hudson/
Draco - http://draconet.sourceforge.net/
CruiseControl - http://cruisecontrol.sourceforge.net/
Well unfortunately if you do this, then you will, as you're experiencing, an AppDomain restart. So unless you do as Espo has said and use svn export, you'll see this issue.
Would it be easier to write a 2 line batch file that svn updates a local copy and then copies the files across?
An app pool recycle should not be that big a deal. Is your issue perhaps that your users are losing their session when this happens? If so, switch to StateServer or SQLServer sessions instead of using InProc.
Subversion 1.7 and up doesn't create .svn files in each subdirectory anymore which makes it possible to do what you want without the .svn files getting in the way.
I'm a little late to the game but I'll throw my 2 cents:
You can use svn export passing a -r REV param. This enables you to rollback your app to the specified revision.
So you can use:
svn export REPOSITORY DESTINATION --force to update to HEAD (current state of you application)
or
svn export REPOSITORY -r REV DESTINATION --force to update to an other revision (maybe you should be using tags)
Don´t forget the --force param so it can replace the existing files in DESTINATION.