NYCPHP Meetup

[Cliff Hirsch]

Cliff,
> I haven't come across anything that does what you are trying to do. But, may I
> ask why? You are trying to keep track of something that svn already keeps
> track of for you. I say use the tool like it was intended. If you are that
> unsure of the commit, make a note of the current revision as a baseline. You
> can use the log viewer (in both CLI and Tortise) to see the diffs between any
> revision, at any point in the future. If you have to, you can go back to the
> baseline. Either by specific file, or the whole commit. I think of it as
> "reverse merge" because you are merging the old revision changes in to a new
> revision file. 
> 
> The closest I can come to answering your question is the revision graph. It
> will produce a hierarchical representation of all the major changes to a
> file., but might not tell you what you are looking for.
> 
I guess I need to learn more about the patch process. Here¹s what I¹m
thinking. The vendor¹s upgrade will attempt to patch hundreds of files. Yet,
I¹m only concerned about the 100 or so that I have changed. So when things
fail, where do I look? A diff post-upgrade will show hundreds of file
changes, yet I¹m only concerned about  the files I previously changed.

Now I have heard that patches will fail if I have made changes. The diff
file is the diff between the vendor¹s new code and the original code, not
the code with my changes. If this is the case, it will be simple to see
where the patches fail. This would make life a lot easier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070813/df7ddc54/attachment.html>