[filesystem] [svn] How to remove V2 files without loss of V3 history?
The boost/filesystem directory currently looks like this: v2 config.hpp // actual header convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp v3 config.hpp // actual header convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp config.hpp // forwards to v2/config.hpp or v3/config.hpp convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp It is time to remove the dual version support. What I'd like to do is: * create a branch, * switch to it, * delete the top level forwarding headers, * move the v3 headers up to boost/filesystem, * delete the v2 and v3 directories, * modify the headers as needed, * merge back to trunk. At the completion of the merge, the history for the boost/filesystem headers should include the full history of what were the boost/filesystem/v3 headers. What are the svn commands to accomplish that? Thanks, --Beman
AMDG On 03/18/2012 04:52 AM, Beman Dawes wrote:
The boost/filesystem directory currently looks like this:
v2 config.hpp // actual header convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp v3 config.hpp // actual header convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp config.hpp // forwards to v2/config.hpp or v3/config.hpp convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp
It is time to remove the dual version support.
What I'd like to do is:
* create a branch, * switch to it, * delete the top level forwarding headers, * move the v3 headers up to boost/filesystem, * delete the v2 and v3 directories, * modify the headers as needed, * merge back to trunk.
At the completion of the merge, the history for the boost/filesystem headers should include the full history of what were the boost/filesystem/v3 headers.
What are the svn commands to accomplish that?
cd boost/filesystem svn cp ^/trunk/boost/filesystem ^/branches/filesystem_v3/boost/filesystem svn switch ^/trunk/boost/filesystem svn rm *.hpp svn mv v3/*.hpp . svn rm v2 v3 # modify headers svn commit -m "Remove Filesystem V2" svn switch ^/trunk/boost/filesystem svn merge --reintegrate ^/branches/filesystem_v3/boost/filesystem svn commit -m "Merge back to trunk" FWIW, if you're doing this in one go, there's no good reason to create a branch. In Christ, Steven Watanabe
On 18 March 2012 13:14, Steven Watanabe <watanabesj@gmail.com> wrote:
cd boost/filesystem svn cp ^/trunk/boost/filesystem ^/branches/filesystem_v3/boost/filesystem svn switch ^/trunk/boost/filesystem
Should that be: svn switch ^/branches/filesystem_v3/boost/filesystem
svn rm *.hpp svn mv v3/*.hpp . svn rm v2 v3 # modify headers svn commit -m "Remove Filesystem V2" svn switch ^/trunk/boost/filesystem svn merge --reintegrate ^/branches/filesystem_v3/boost/filesystem svn commit -m "Merge back to trunk"
FWIW, if you're doing this in one go, there's no good reason to create a branch.
Also, if we eventually switch to git, I don't think git will understand that the file has moved, since there was already a file in the new location. There might be a benefit to having an intermediate version with the file missing (although, there might not, I don't how well the git conversion will handle it).
on Sun Mar 18 2012, Daniel James <dnljms-AT-gmail.com> wrote:
On 18 March 2012 13:14, Steven Watanabe <watanabesj@gmail.com> wrote:
cd boost/filesystem svn cp ^/trunk/boost/filesystem ^/branches/filesystem_v3/boost/filesystem svn switch ^/trunk/boost/filesystem
Should that be:
svn switch ^/branches/filesystem_v3/boost/filesystem
svn rm *.hpp svn mv v3/*.hpp . svn rm v2 v3 # modify headers svn commit -m "Remove Filesystem V2" svn switch ^/trunk/boost/filesystem svn merge --reintegrate ^/branches/filesystem_v3/boost/filesystem svn commit -m "Merge back to trunk"
FWIW, if you're doing this in one go, there's no good reason to create a branch.
Also, if we eventually switch to git, I don't think git will understand that the file has moved, since there was already a file in the new location. There might be a benefit to having an intermediate version with the file missing (although, there might not, I don't how well the git conversion will handle it).
I don't think so. John's SVN->Git conversion knows about svn mv operations, but if you delete and recreate a file somewhere else it isn't going to realize you moved something. Of course, Git can often reconstruct that information, as long as it isn't "crossing branches"... but again I think what you're talking about isn't going to help. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 18 March 2012 15:27, Dave Abrahams <dave@boostpro.com> wrote:
on Sun Mar 18 2012, Daniel James <dnljms-AT-gmail.com> wrote:
On 18 March 2012 13:14, Steven Watanabe <watanabesj@gmail.com> wrote:
cd boost/filesystem svn cp ^/trunk/boost/filesystem ^/branches/filesystem_v3/boost/filesystem svn switch ^/trunk/boost/filesystem
Should that be:
svn switch ^/branches/filesystem_v3/boost/filesystem
svn rm *.hpp svn mv v3/*.hpp . svn rm v2 v3 # modify headers svn commit -m "Remove Filesystem V2" svn switch ^/trunk/boost/filesystem svn merge --reintegrate ^/branches/filesystem_v3/boost/filesystem svn commit -m "Merge back to trunk"
FWIW, if you're doing this in one go, there's no good reason to create a branch.
Also, if we eventually switch to git, I don't think git will understand that the file has moved, since there was already a file in the new location. There might be a benefit to having an intermediate version with the file missing (although, there might not, I don't how well the git conversion will handle it).
I don't think so. John's SVN->Git conversion knows about svn mv operations, but if you delete and recreate a file somewhere else it isn't going to realize you moved something.
It doesn't really matter whether the conversion understands 'svn mv', since git doesn't track moves. So moving one file over another in a single commit makes that difficult. For example: git init echo 'A' > a.txt git add a.txt git commit -m "a.txt" echo 'B' > b.txt git add b.txt git commit -m "b.txt" git rm a.txt git mv b.txt a.txt git commit -m "Move b.txt to a.txt" git log --follow a.txt commit 4edcc668a230580ef268446b31528ba343fa0ae0 Author: Daniel James <dnljms@gmail.com> Date: Sun Mar 18 16:10:00 2012 +0000 Move b.txt to a.txt commit caf99a35836af843549190e12b8531a9e3bbbe82 Author: Daniel James <dnljms@gmail.com> Date: Sun Mar 18 16:10:00 2012 +0000 a.txt Add a remove: git init echo 'A' > a.txt git add a.txt git commit -m "a.txt" echo 'B' > b.txt git add b.txt git commit -m "b.txt" git rm a.txt # Extra remove here: git commit -m "Remove a.txt" git mv b.txt a.txt git commit -m "Move b.txt to a.txt" git log --follow a.txt commit ed22d4fef500fb149128ee3a867c24c0c51b76f9 Author: Daniel James <dnljms@gmail.com> Date: Sun Mar 18 16:10:26 2012 +0000 Move b.txt to a.txt commit 4a4afd388d012c22bbf9e188fe02702d2cbd5280 Author: Daniel James <dnljms@gmail.com> Date: Sun Mar 18 16:10:26 2012 +0000 b.txt
on Sun Mar 18 2012, Daniel James <dnljms-AT-gmail.com> wrote:
On 18 March 2012 15:27, Dave Abrahams <dave@boostpro.com> wrote:
on Sun Mar 18 2012, Daniel James <dnljms-AT-gmail.com> wrote:
On 18 March 2012 13:14, Steven Watanabe <watanabesj@gmail.com> wrote:
cd boost/filesystem svn cp ^/trunk/boost/filesystem ^/branches/filesystem_v3/boost/filesystem svn switch ^/trunk/boost/filesystem
Should that be:
svn switch ^/branches/filesystem_v3/boost/filesystem
svn rm *.hpp svn mv v3/*.hpp . svn rm v2 v3 # modify headers svn commit -m "Remove Filesystem V2" svn switch ^/trunk/boost/filesystem svn merge --reintegrate ^/branches/filesystem_v3/boost/filesystem svn commit -m "Merge back to trunk"
FWIW, if you're doing this in one go, there's no good reason to create a branch.
Also, if we eventually switch to git, I don't think git will understand that the file has moved, since there was already a file in the new location. There might be a benefit to having an intermediate version with the file missing (although, there might not, I don't how well the git conversion will handle it).
I don't think so. John's SVN->Git conversion knows about svn mv operations, but if you delete and recreate a file somewhere else it isn't going to realize you moved something.
It doesn't really matter whether the conversion understands 'svn mv', since git doesn't track moves.
No, it really does matter, at least for branch tracking. We know git doesn't track moves, but the conversion does need to track svn cp and svn mv. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 18 March 2012 17:36, Dave Abrahams <dave@boostpro.com> wrote:
on Sun Mar 18 2012, Daniel James <dnljms-AT-gmail.com> wrote:
On 18 March 2012 15:27, Dave Abrahams <dave@boostpro.com> wrote:
on Sun Mar 18 2012, Daniel James <dnljms-AT-gmail.com> wrote:
Also, if we eventually switch to git, I don't think git will understand that the file has moved, since there was already a file in the new location. There might be a benefit to having an intermediate version with the file missing (although, there might not, I don't how well the git conversion will handle it).
I don't think so. John's SVN->Git conversion knows about svn mv operations, but if you delete and recreate a file somewhere else it isn't going to realize you moved something.
I wasn't saying the file should be deleted and recreated. I was saying that the file in the destination should be deleted in a revision before the file is moved to that destination. So that git will understand that they are different files. i.e. svn rm boost/filesystem/path.hpp svn commit svn mv boost/filesystem/v3/path.hpp boost/filesystem/path.hpp svn commit (although obviously not doing a single file at a time)
It doesn't really matter whether the conversion understands 'svn mv', since git doesn't track moves.
No, it really does matter, at least for branch tracking. We know git doesn't track moves, but the conversion does need to track svn cp and svn mv.
We're not talking about tacking branches. We're talking about retaining the history of a moved file. Did you look at the examples I posted? They illustrate the issue.
on Sun Mar 18 2012, Daniel James <dnljms-AT-gmail.com> wrote:
On 18 March 2012 17:36, Dave Abrahams <dave@boostpro.com> wrote:
on Sun Mar 18 2012, Daniel James <dnljms-AT-gmail.com> wrote:
On 18 March 2012 15:27, Dave Abrahams <dave@boostpro.com> wrote:
on Sun Mar 18 2012, Daniel James <dnljms-AT-gmail.com> wrote:
Also, if we eventually switch to git, I don't think git will understand that the file has moved, since there was already a file in the new location. There might be a benefit to having an intermediate version with the file missing (although, there might not, I don't how well the git conversion will handle it).
I don't think so. John's SVN->Git conversion knows about svn mv operations, but if you delete and recreate a file somewhere else it isn't going to realize you moved something.
I wasn't saying the file should be deleted and recreated. I was saying that the file in the destination should be deleted in a revision before the file is moved to that destination. So that git will understand that they are different files. i.e.
svn rm boost/filesystem/path.hpp svn commit svn mv boost/filesystem/v3/path.hpp boost/filesystem/path.hpp svn commit
(although obviously not doing a single file at a time)
Ah. Thanks for explaining. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Daniel James <dnljms@gmail.com> writes:
I don't think so. John's SVN->Git conversion knows about svn mv operations, but if you delete and recreate a file somewhere else it isn't going to realize you moved something.
It doesn't really matter whether the conversion understands 'svn mv', since git doesn't track moves. So moving one file over another in a single commit makes that difficult.
No, to Git it doesn't matter, but the aspect of my SVN->Git converter which will break files groups into submodules automatically it does matter. John
On Sun, Mar 18, 2012 at 9:14 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 03/18/2012 04:52 AM, Beman Dawes wrote:
The boost/filesystem directory currently looks like this:
v2 config.hpp // actual header convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp v3 config.hpp // actual header convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp config.hpp // forwards to v2/config.hpp or v3/config.hpp convenience.hpp exception.hpp fstream.hpp operations.hpp path.hpp
It is time to remove the dual version support.
What I'd like to do is:
* create a branch, * switch to it, * delete the top level forwarding headers, * move the v3 headers up to boost/filesystem, * delete the v2 and v3 directories, * modify the headers as needed, * merge back to trunk.
At the completion of the merge, the history for the boost/filesystem headers should include the full history of what were the boost/filesystem/v3 headers.
What are the svn commands to accomplish that?
cd boost/filesystem svn cp ^/trunk/boost/filesystem ^/branches/filesystem_v3/boost/filesystem svn switch ^/trunk/boost/filesystem svn rm *.hpp svn mv v3/*.hpp . svn rm v2 v3 # modify headers svn commit -m "Remove Filesystem V2" svn switch ^/trunk/boost/filesystem svn merge --reintegrate ^/branches/filesystem_v3/boost/filesystem svn commit -m "Merge back to trunk"
OK, thanks! I'll give it a try.
FWIW, if you're doing this in one go, there's no good reason to create a branch.
The actual steps are somewhat more complex because there are a parallel set of changes to libs/filesystem. I'll do some testing along the way. Using Git on other projects, I've gotten used to creating branches more often and doing commits along the way. Makes partial rollbacks much easier and leaves the trunk ("master" on Git) in a clean state until I'm 100% certain the changeover is ready for prime time. --Beman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I've read the discussion and want to provide some words of caution. Am 18.03.12 14:14, schrieb Steven Watanabe:
cd boost/filesystem svn cp ^/trunk/boost/filesystem ^/branches/filesystem_v3/boost/filesystem svn switch ^/trunk/boost/filesystem svn rm *.hpp svn mv v3/*.hpp . svn rm v2 v3 # modify headers svn commit -m "Remove Filesystem V2" svn switch ^/trunk/boost/filesystem svn merge --reintegrate ^/branches/filesystem_v3/boost/filesystem svn commit -m "Merge back to trunk"
The --reintegrate option requires a merge of trunk to the branch beforehand if there have been commits to trunk since creation of the branch. Simply not using this option will merge the changes into the trunk correctly here. Using a separate branch to do the work will encourage a single merge into the trunk at the end. The commit "Merge back to trunk" will delete files and create moved files in their place. This triggers the git move problem Daniel mentioned. You can merge two times, though, by first merging just up to that revision that deleted the files and then merging the rest. Creating the branch from /trunk enables working on /boost/filesystem and /libs/filesystem at the same time at no additional costs with svn. Best Regards, Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk9pCY8ACgkQhAOUmAZhnmoM1QCeIwN4/w6UD7DWNAKN3YUvp36m sAIAniHcGP1QlIgrE79e8P/Xo6Uyj6Rk =Qb9T -----END PGP SIGNATURE-----
On Tue, Mar 20, 2012 at 6:49 PM, Frank Birbacher <bloodymir.crap@gmx.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
I've read the discussion and want to provide some words of caution.
Am 18.03.12 14:14, schrieb Steven Watanabe:
cd boost/filesystem svn cp ^/trunk/boost/filesystem ^/branches/filesystem_v3/boost/filesystem svn switch ^/trunk/boost/filesystem svn rm *.hpp svn mv v3/*.hpp . svn rm v2 v3 # modify headers svn commit -m "Remove Filesystem V2" svn switch ^/trunk/boost/filesystem svn merge --reintegrate ^/branches/filesystem_v3/boost/filesystem svn commit -m "Merge back to trunk"
The --reintegrate option requires a merge of trunk to the branch beforehand if there have been commits to trunk since creation of the branch. Simply not using this option will merge the changes into the trunk correctly here.
Thanks for the heads up on this. There haven't been any changes filesystem in trunk since the branch was created, so no problem there.
Using a separate branch to do the work will encourage a single merge into the trunk at the end.
Yes, and that's part of the objective, along with retaining history.
The commit "Merge back to trunk" will delete files and create moved files in their place. This triggers the git move problem Daniel mentioned.
IIUC, you are saying that in svn, deleting a file and then moving another in its place in a single commit will lose the history of the new file. Also that git would have the same problem. I can confirm that did indeed happen in svn. The history was OK on the branch, but was badly whacked after merging back to the trunk working copy.
You can merge two times, though, by first merging just up to that revision that deleted the files and then merging the rest.
Nuts. I didn't happen to do branch commits at exactly the right point in the process. I'll repeat the process per your suggestion, and report back.
Creating the branch from /trunk enables working on /boost/filesystem and /libs/filesystem at the same time at no additional costs with svn.
And allowed testing along the way. That was important as a number of issues came up that had to be dealt with. Thanks, --Beman
AMDG On 03/23/2012 02:44 AM, Beman Dawes wrote:
The commit "Merge back to trunk" will delete files and create moved files in their place. This triggers the git move problem Daniel mentioned.
IIUC, you are saying that in svn, deleting a file and then moving another in its place in a single commit will lose the history of the new file. Also that git would have the same problem.
SVN should handle this just fine.
I can confirm that did indeed happen in svn. The history was OK on the branch, but was badly whacked after merging back to the trunk working copy.
That's odd. I tried doing a merge to trunk@77491 with svn 1.7.4 and it seemed to work correctly. The command I uses was: svn merge https://svn.boost.org/svn/boost/branches/filesystem-v3 I tried svn log boost/filesystem/config.hpp and the output looked right.
You can merge two times, though, by first merging just up to that revision that deleted the files and then merging the rest.
Nuts. I didn't happen to do branch commits at exactly the right point in the process.
I'll repeat the process per your suggestion, and report back.
Creating the branch from /trunk enables working on /boost/filesystem and /libs/filesystem at the same time at no additional costs with svn.
And allowed testing along the way. That was important as a number of issues came up that had to be dealt with.
In Christ, Steven Watanabe
On Fri, Mar 23, 2012 at 11:13 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 03/23/2012 02:44 AM, Beman Dawes wrote:
The commit "Merge back to trunk" will delete files and create moved files in their place. This triggers the git move problem Daniel mentioned.
IIUC, you are saying that in svn, deleting a file and then moving another in its place in a single commit will lose the history of the new file. Also that git would have the same problem.
SVN should handle this just fine.
I can confirm that did indeed happen in svn. The history was OK on the branch, but was badly whacked after merging back to the trunk working copy.
That's odd. I tried doing a merge to trunk@77491 with svn 1.7.4 and it seemed to work correctly. The command I uses was:
svn merge https://svn.boost.org/svn/boost/branches/filesystem-v3
I tried svn log boost/filesystem/config.hpp
and the output looked right.
Hum... "svn log boost/filesystem/config.hpp" at a quick glance looks right, as you indicated. But TortoiseSVN's log produces a somewhat different history that includes entries not in the svn log output! I'm now totally confused and will need to do some checking to see which, if either, is correct, and also why they differ. --Beman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Am 24.03.12 13:20, schrieb Beman Dawes:
Hum... "svn log boost/filesystem/config.hpp" at a quick glance looks right, as you indicated. But TortoiseSVN's log produces a somewhat different history that includes entries not in the svn log output!
TortoiseSVN can lookup the history of merges. That is: the svn log shows a single commit for the merge (totally correct), but TortoiseSVN uses the diff on the svn:mergeinfo to lookup the merged revisions and their commit messages and injects them into the regular log. There is a checkbox for this option and the entries should look dimmed, IIRC. HTH, Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk9tzJMACgkQhAOUmAZhnmoRqQCePvkRod6V73Erg3wNbQfUxFKd PWgAoJLXobnjhSnBX4tZf0sRDKbKtGD5 =DwBO -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Am 23.03.12 10:44, schrieb Beman Dawes:
The commit "Merge back to trunk" will delete files and create moved files in their place. This triggers the git move problem Daniel mentioned.
IIUC, you are saying that in svn, deleting a file and then moving another in its place in a single commit will lose the history of the new file. Also that git would have the same problem.
I meant something different here. On the branch: if you commit deletion of files separate from the commit of new (moved) files in their place you have one commit that deletes some files and another commit that creates files. This is good. When you merge the whole branch back to trunk and commit there you will end up with one commit on the trunk that contains all changes, e.g. it will delete and recreate files in one go. This is perfectly fine with SVN. IIUC, it will break history in git. To put it differently: on the branch there can be 1, 5, or 100 commits, but the merge on the trunk will be just a single commit containing all changes. Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk9s/UEACgkQhAOUmAZhnmpG6gCdHlRxpSvsJm0TvD2UWmJBUtOn igoAn3EbJ46lshZhVsqBzdSplg0xyuW7 =yk2v -----END PGP SIGNATURE-----
participants (6)
-
Beman Dawes -
Daniel James -
Dave Abrahams -
Frank Birbacher -
John Wiegley -
Steven Watanabe