Not a problem I ran into directly, but fellow Gentoo developer did
(CC'd), and I couldn't find a reasonable answer as the person that they
were asking hard Git questions of (I _think_ I saw it somewhere on the
web before, but I can't find it atm).
I'm personally a CVS and then Git guy, with SVN usage as a distant
relative. I wouldn't personally host a project in SVN [and I find
git-svn to be a miracle-worker in helping me out].
Some rough problem background:
- They have a SVN repo, with a few areas under trunk. Relevant to us are
'submitted' and 'reviewed'. Under each, the unique content is in
directories that are treated as single units.
- It is normal to have both portions checked out at once.
- There are users that can put stuff into the 'submitted' portion.
- There are a subset of users that can commit stuff to 'reviewed'.
- The reviewer subset of users is orthogonal to the people that can
commit to 'reviewed'.
- $Header$ expansion is disabled in the SVN repo.
- Git v1.5.1.4
Problem:
The Git docs say to use plain 'cp' where svn-cp would be used, as Git
detects copies after-the-fact. However, doing so in Git does not appear
to sanely preserve the history in Git, or when the files are committed
back to the SVN tree (git-svn dcommit).
Here's an example of their process done purely with SVN.
('submitted' = sunrise).
http://overlays.gentoo.org/proj/sunrise/changeset/3687
Specifically of interest are the portions that have '(copied from
$OLDPATH)'
'svn log' produces this output:
http://rafb.net/p/bETJkV31.html
The bottom two entries are relevant to the file in it's location inside
the 'submitted' tree, and were copied to the history in the 'reviewed'
tree.
Here's the same thing, done with plain cp per the Git documentation.
The files that previously showed 'copied from ...' just show up as new,
and their history has remained separate.
http://overlays.gentoo.org/proj/sunrise/changeset/3687
If one looks at the SVN log between the two styles on a file that is
newly added, the SVN case includes the history of the file in the old
location, whereas Git does not. Git only has the commit that introduced
it at it's present location.
'svn-cp' revision list:
http://overlays.gentoo.org/proj/sunrise/log/reviewed/app-admin/blockhosts/blockhosts-2.0.3.ebuild?rev=3687
'git using plain cp' revision list:
http://overlays.gentoo.org/proj/sunrise/log/reviewed/dev-libs/dswifi/dswifi-0.3.1.ebuild?rev=3749
Git SHOULD have included this history:
http://overlays.gentoo.org/proj/sunrise/log/sunrise/dev-libs/dswifi/dswifi-0.3.1.ebuild?rev=3749
While researching this for the other guy, I notice a related defect in
SVN's svn-cp implementation, but pertaining to existing files.
- The actions of 'svn-cp' that create a new file copy the existing
history.
- The actions of 'svn-cp' that do NOT create a new file only applies the
changes as a single commit, without copying any history.
Thinking about the problem from the perspective of what it's supposed to
do, I think the correct action in BOTH cases would be to take the
portions of both commits that lead to the present state of the file in
'submitted', and tell Git that they are relevant to the history of the
file in 'reviewed'. As to how best to go about this, I'm not certain.
--
Robin Hugh Johnson
Gentoo Linux Developer & Council Member
E-Mail : robbat2@xxxxxxxxxx
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Attachment:
pgpgKYxCUqaAA.pgp
Description: PGP signature
