merging of trunk to fortran-dev?

[Steve Kargl]

On Tue, Dec 29, 2009 at 09:48:41PM +0100, Tobias Schl?ter wrote:
> On 2009-12-29 21:31, Janus Weil wrote:
> >>>although Daniel's constructor patch presently seems to have no overlap
> >>>with the OOP stuff on the fortran-dev branch, it may not be the
> >>>optimal solution to have them both on the same branch.
> >>>
> >>>We still have the fortran-experiments branch, don't we? It seems this
> >>>hasn't been used for about two years, so we could just update it to
> >>>current trunk and put Daniel's constructor work there. Or is there any
> >>>reason why we can/should not do that?
> >>
> >>The old fortran-experiments branch was/is severely messed-up.
> >>It may be painful to bring it up to date.
> >
> >Ok, I didn't know that. I proposed this because I thought it would be easy.
> >
> >Also I won't oppose the fortran-dev plan if all other alternatives
> >turn out to be more inconvenient.
> 
> I tried the simplest thing possible, namely
>   svn cp svn+ssh://gcc.gnu.org/svn/gcc/trunk \
>          svn+ssh://gcc.gnu.org/svn/gcc/branches/fortran-experiments \
>     -m "Reset branch to trunk."
> 
> Unfortunately, this copied trunk to a subdirectory of 
> fortran-experiments, so I removed that copy again.  I can't find another 
> way of syncing two directories in svn, therefore I would suggest that 
> you simply start a new branch.  svn rm'ing fortran-experiments and then 
> starting the branch anew seems pointless, it would only make history 
> more difficult to search through.
> 

I'm going by my failing memory :-)  The problems were caused
at least partially in that I used "svn merge" commands and others
(and even maybe me) used the svnmerge.py script to sync the
branch.  Mind you these were older vesions of svn and svnmerge.  
To compound the problem, I had limited disk space so used 
"svn switch" to point unneeded directories (e.g., ada, objc, etc)
to emptrydir.  In the end, some svn meta data got messed up.  Dan
Berlin helped fixed some of the issues, but it seemed like I was
always repairing damage.


-- 
Steve