I know svn diff, but it only gives the difference between my working copy and the current revision that I last checked out from the repository.
I want the difference between my working copy today and my working copy yesterday. (Maybe like a 'Track Changes' in MS Word.)
I am working on a large code base, thousands of files and folders, thousands of lines per file. I currently do code compilation on Ubuntu VM, and keeping track of different versions of each file via multiple different copies in a Windows folder. Then I also have another Windows folder working copy for SVN commits. I also have another Ubuntu directory working copy for SVN commits in case I want to commit from Linux. This gets quite confusing. Hoping for a good solution.
Update 1:
I recently created a local SVN server on my Ubuntu VM that could take care of the changes that I make. But I faced the problem of how to transfer the updated company server source codes to my local server and vice versa.
So this doesn't work out.
Update 2:
I managed to create a branch from the trunk of the repository on the company server. (Thanks to advice from Robert Levy.)
I transferred all my changes to this branch using diff and patch commands on Ubuntu.
By this time I have lots of changes done to the source codes for testing only, so I would not merge these changes to the trunk.
However I would be making subsequent changes that I wish to merge into the trunk.
I am expecting some conflicts because the new change (that I want to merge) would be one line before the previous change (that I don't want to merge) so the diff would not be clean.
Is it a good idea to create yet another branch for the purpose of merging? What are the steps or potential conflict resolutions?
Update 3:
I am getting used to merging trunk and branches with Tortoise SVN, hopefully.
(Should I compile on branch 'to_test' or branch 'to_merge' or trunk?) One step at a time.
Update 4:
I now edit and cross-compile the toolchain on branch 'to_test' in Ubuntu. Now and then, I merge the trunk to branch 'to_merge', and merge the trunk to branch 'to_test' (resolving any conflicts). When my feature is complete, I would merge selected changes from branch 'to_test' to branch 'to_merge' then merge all from branch 'to_merge' to the trunk. All the merging is done in TortoiseSVN and KDiff3 on Windows so it is pretty convenient.
This is certainly a great leap forward from manually making multiple backup copies of individual files.
Thanks, Stack Exchange.
Update 5:
I now have two branches: 'Understanding' and 'Development'. In the 'Understanding' branch, I can litter it with lots of printk debugging statements. In the 'Development' branch, I make only the changes necessary for the required feature. Once the feature is complete, I would merge all from the 'Development' branch to the trunk. My company uses the 'stable trunk' policy. The 'trunk' should be ready for production.
In the 'Understanding' branch, I committed all my past manual changes at one shot after using a diff patch. So it would be impossible to select individual changes for merging. Therefore, my 'Understanding' branch and 'Development' branch are independent from each other.
Create a branch for yourself. This will be your own private branch where you can feel free to commit changes regularly without fear of impacting anybody else. By committing frequently, you can easily pull up diffs showing what changed in a given day. When you are ready, merge your private branch back up to the main branch so that others can benefit from the awesome work you've done.