>> Since you will never have merge conflicts, why don't you drop the drop
>> dir and recreate it, instead of messing with a merge?
>> svn rm .../drop
>> svn mkdir drop
>> svn copy trunk/some/where drop
>> or keep the dir and delete the contents
>> for /f %i in ('svn ls -N .../drop' do @svn rm %i
>> svn copy ...
> Won't that make all the files look "new" to the person downloading the
> /drop directory?
I'm a bit of a SVN noob and convert, but I've been reading up bigtime this
week, because it is my intention to start implementing version control with
svn on both my personal and work projects, and I have been trying to find
commentary from someone about the exact same thing you want.. except I'm
calling my directory a "live" directory, to leave no question which app
version should be deployed on the live server for our intranet site.
That said, I have been testing the first recommendation (remove the "drop"
dir, then svn copy it again). This does work, and when the user does an
update, only the changed files are updated. I wouldn't be surprised if the
second recommendation (keep dir and delete contents) does not work that
nicely, as you suspect.
So to describe it precisely, here's how am planning to handle things, in a
When ready, put a revision into my tags dir:
svn copy trunk tags/1.0.3
Create a "live" copy of that revision:
svn copy tags/1.0.3 live
After more development, put another revision into my tags dir:
svn copy trunk tags/1.0.4
Remove existing "live", and create a new "live" pointing to new revision:
svn del live
svn copy tags/1.0.4 live
This works!! Only difference here is that I'm doing a svn del rather than
just a filesystem rm of the directory. Does anybody with experience
recommend against this? Especially since a svn update will properly process
any changes, it seems like a great way to go. Only irritant is the necessary
step of committing the delete before recopying the "live" directory.
View this message in context: http://www.nabble.com/Creating-a-drop-folder-tf1938325.html#a5318211
Sent from the Subversion Users forum at Nabble.com.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jul 14 00:46:29 2006