Creating a drop folder

[Tankko <ta...@gmail.com>]

I am working on a project where the clients wants to be able to
download the "builds" (or "drops" as we call them) directly from the
repository.  I'd rather they not have access to all the daily updates
the programmers do, or have access to versions that happen between the
agreed upon drop dates.

My solution that to create a drop branch in the repo:

myproj/trunk
myproj/drop

and give the client read-only access to only myproj/drop

Then, when a drop was due, I can just merge the /trunk into /drop.  If
there are any little fixes that need to be down right after the drop,
I just do another quick merge.

Is this the best way to do this?

My problem is that I can't seem to get it to work.  It never seems to
want to merge.  If new files are created in /trunk, the merge just
complains.  Shouldn't the merge be able to create/copy the new files
in /drop?

I need this to be a 100% automated process.  Since /drop is read-only
by the client and I will only be merging from /trunk, there should
never be any conflicts.

Am I thinking about this the right way?

Tankko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Re: Creating a drop folder

[Joshua Curtiss <j....@rvc.cc.il.us>]

Tankko wrote:
> 
>> 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
sample scenario:

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.

Josh
-- 
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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Creating a drop folder

[Tankko <ta...@gmail.com>]

> Sure it should. Sounds like you may not be issuing the correct merge
> command. Show us exactly what you typed.

I think I know what I was doing wrong.  I need to specify the revision
to merge from, I was assuming HEAD would just bring it up-to-date, I
see now.

But, this brings up the problem of automation.  Since SVN doesn't have
"tags" to just mark a revision number, it's much harder for the script
to know when the last "drop" was done.

(P.S.  I am running on windows, so I don't have all the power of bash)

> Should be doable. You'll need to script it carefully. You may want to
> look into the svnmerge script which may already do most of this
> carefulness for you.

I'll look into this.  Thanks.

Tankko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Creating a drop folder

[Ryan Schmidt <su...@ryandesign.com>]

On Jul 13, 2006, at 18:10, Tankko wrote:

> My problem is that I can't seem to get it to work.  It never seems to
> want to merge.  If new files are created in /trunk, the merge just
> complains.  Shouldn't the merge be able to create/copy the new files
> in /drop?

Sure it should. Sounds like you may not be issuing the correct merge  
command. Show us exactly what you typed.


> I need this to be a 100% automated process.  Since /drop is read-only
> by the client and I will only be merging from /trunk, there should
> never be any conflicts.

Should be doable. You'll need to script it carefully. You may want to  
look into the svnmerge script which may already do most of this  
carefulness for you.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org