[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Thu, 2005-11-03 at 17:59 +0100, Julien Cugnière wrote:
> I think you missed something, because that's not what's supposed to
> happen (I checked :-). This looks suspicious because b.txt is not a
> "target" of revision 102, but rather its result. Also a.txt is not
> supposed to be "A"dded in revision 102... What command did you use ?
Hm, yes, I actually had used the latest revision always.
> > But, I think the case we will have in Allegro is like this:
> > "branch" is the 4.2.x, "trunk" 4.3.x (or any other directory names)
> >
> > * revision 101: trunk/a.txt is renamed to b.txt
> > * revision 102: trunk/b.txt is modified
> >
> > And now, you can simply merge the changes from trunk to the 4.2.0
> > branch. (Either including or excluding the name change, depending on
> > which revisions you specify.)
>
> Attached is a shell script that shows that this unfortunately won't
> work. If you merge without the rename, svn complains. If you merge with
> the rename, you fall back to the situation I described in the previous
> mail where you lose all modifications on the branch :-(
>
> Note: the script was made using the MSys shell under windows, so it
> might need adjusting under Linux. Also beware, it contains two "rm -rf"
> at the beginning :-)
Thanks, nice. Worked under Linux, and yeah, I was wrong.. SVN doesn't
behave here as I would have expected.
So merging renamed files will have to be done on a file per file basis.
The lost update case where also such a file in branch is modified
wouldn't appear I think (at least when merging from 4.3.x to 4.2.x.. but
it might appear in other branches we might create..). But well, I have
no idea how Peter's (hm, is Peter vs. Pete a way to keep you two
apart? :) ) does the CVS merging. I guess the SVN way will be no easier
than the CVS then (except the learning curve for someone doing it the
first time).
/me goes and installs gnu arch.. :)
--
Elias Pschernig