Well...
SVN log can do the trick. Remember you can use either the revision
number or the date of the revision. If you created a tag, a "svn log"
on that tag (with the --verbose and --stop-on-copy switches) will give
you the revision number and URL that tag is based upon.
The verbose flag will show you the names of the files committed. It
shouldn't be too difficult to pipe the output of an svn log and parse
the names of the changed files. In fact, I did this myself in both
Perl and PHP. You should be able to also use the SVN API to pull out
the information you want too.
On Thu, Aug 27, 2009 at 3:00 PM, Paul Keating<keating_at_acm.org> wrote:
> In my environment the real code doesn't live in the working copy, it lives
> in the database along with the data. If you change code in the database, a
> daemon writes that change to your working copy behind your back. And every
> so often you will check those changes in.
>
> "Code" here is a broad concept that includes textfiles, spreadsheet-like
> objects and SQL where-clauses that have been parsed into search trees.
>
> The database for my upgrade project gets refreshed nightly from the
> production environment. It's a database restore, all or nothing. After that,
> there is an upgrade job that makes the database look the way the new version
> of the software expects.
>
> After the refresh+upgrade I would like to put back all of the checked-in
> changes, so that when the project team gets in in the morning, they have
> data as at close of business yesterday, but with all of their project code
> as they last checked it in.
>
> So I want to get the names of all the files on the project branch that have
> had changes committed since the revision that created the project branch. I
> can then use that to put the changed code in the database back the way it
> was before the refresh+upgrade. There are good reasons for wanting to
> restore only the code that has been checked in: the code in the database may
> have changes that were put there by the upgrade and so are not in the
> repository or in any working copy yet, so restoring that code would reverse
> the upgrade.
>
> I'm pretty sure these names can be wheedled out of svn info or svn status,
> but that seems to involve turning those commands on their heads and I'm
> having trouble with the mental gymnastics.
>
>
> --
> Paul Keating
> The Hague
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2387988
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
>
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388096
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-28 08:45:53 CEST