On 26.06.2011 23:15, Michael Stahl wrote:
On 23.06.2011 19:15, Mathias Bauer wrote:
But now I recognized that this idea was based on the wonderful feature
that the "git extended" diff format offers. It allows to have file
removal, addition or renaming (that includes moves in the tree) or file
attribute changes in the diff and by using "hg patch" (and not the patch
command of the OS) all these changes apply nicely in the target
repository.
I didn't find a support for this in svn, but maybe there is something
similar or comparable we could use.
just found this:
http://subversion.apache.org/docs/release-notes/1.7.html#patch
"svn patch will apply unidiff changes to existing files just like third
party patch tools. It will also add newly created files to version
control, and delete files and directories which are left empty after
patching."
seems like this patch format is finally supported in SVN 1.7.
pity that 1.7 doesn't seem to be released yet :(
Another option would be to commit the initial source code (the code that
is directly retrieved from the software grant from Oracle) into a local
Mercurial repository, add all the patches and then convert this into an
svn repository.
hmm... perhaps we could first merge all CWSes that are
nominated/finished anyway into the HG OOO340 repo, then import the
result into SVN...
We can't look at this only from a technical POV. We also should try to
avoid more legal work as this will slow down the integration. As I
wrote, patches are easy as they are owned by those who made them, on
whatever files. And as long as the base where you apply the patches to
is "clean", you can't get into legal trouble.
So I recommned to look for ways to integrate open CWS as patches. The
worst case for this would be to use an intermediate hg repo (created
from the svn repro), but it will work.
Regards,
Mathias
