> -----Original Message-----
> From: Anastasios Angelidis [mailto:voodoo@videotron.ca]
> >You could also walk the new revisions 'svn log -v -q -r
> >OLD_BASELINE+1:NEW_BASELINE url' and analyze the changed file. It
> >should be trivial to script that to get the delta.
> So I would have to at least know the revision when the 3 files where
> checked out
<quibble>
Check outs do not create a revision. Only commits/check-ins do.
</quibble>
> So I would have to at least know ...
> the revison once the last check in hapenned for those
> particular files?
I'm assuming that you do some kind of release management...
svn://myserver/project/trunk, revision 123 went to production on
2006.08.01.
Or that you store the url+revision number on the web server somewhere
for reference.
I'm also assuming that you're working in a single code tree and not
cherry picking what files' changes get deployed.
I'm also assuming that you're deploying from the trunk in a sequential
manner. If you're building custom deployments from tags, then my psuedo
code won't work (it assumes you deploy rev 123 on trunk, and that the
next three changes on the trunk were your three files (say revision
126.)
Another way to capture the delta, is to
-branch/tag from the old_baseline
-merge the revisions containing the changes you want into the
branch/tag
-Use svn status to determine the delta or commit and analyze
'svn log -q -v' to get the delta.
So if there are 10 changes on the trunk, and you only want 3, you can
merge the 3 changes over to the branch/tag. You can then use the pseudo
code in my previous response to generate the delta.
You could also 'svn export -R' both baselines, and use the regular (non
svn) diff to get the delta. You would have to filter the diff output to
get just filenames.
Even easier, you could also serve up your files from within a subversion
workspace. That way you just have to run 'svn update' or 'svn switch'
to update the web server. (You would also need a script to delete
removed files.) Which works pretty well until someone touches a file
directly on the server (instead of doing a commit + svn update) which
causes a merge conflict and prevents that file from being updated. But
that's just a process or beat^H^H^H^Htraining problem.
Other folks have recommend using rsync.
You have lots of options to get your delta, it's just that 'svn diff'
isn't one that you can rely on right now. How you compute your delta
also depends on how you use trunk/branches/tags and how you do your
bug/defect/work tracking and management.
p.s. 'svn diff' ignores empty directories (at least in 1.3.1) which was
another reason for me not to use it.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 4 23:59:37 2006