Guille -bisho- wrote:
> > To make the example more crisp, suppose that in the source repo
> > 'foo' went from a MSWord document to a Latex document in revision
> > 20. Then if you base 'bar' in the target repo off revision 200, then
> > the history of 'bar' in the target repo will show that it started
> > life as a Word document, was a Latex document for a while, then
> > went back to being a Word document, which is not really true.
> >
> > I'm saying: "So what, let's just get svn merge working from multiple
> > repositories even with this flaw".
>
> But the same could happen intra-repository, or even with diff you could
> convert a file into latex without changing the name.
>
> The main problem here is that a move is considered as:
> ORIGINAL BRANCH, version X
> delete [file]
> copy [file from version X] to [newfile]
>
> In another branch, the merged move is considered as:
> delete [file LOCAL BRANCH]
> copy [file from version X of ORIGINAL BRANCH] to [newfile]
>
> In my opinion, a move should be an exportable operation. If you want to
> merge a move, and only a move into another branch, a "svn move" should
> be done, locally into the branch. Right now you get a new file with not
> only changes in the specified changeset X, but all the previous
> changesets in the original repository.
You are right.. we have a similar issue with intra-repository moves,
although the currently implemented solution is different (i.e., svn
links the new target copy directly to the old source original, which
is not possible in a inter-repository merge). Either way, you may
get something perhaps less than "optimal". But that's the nature of
merging when you're not maintaining more meta-information.
This is more support for the argument that inter-repo merges should
be allowed: we don't do much better with intra-repo merges in the same
tricky situations!
> Is the same way of working of properties: When you add a property to a
> file, and try to apply that changeset to another branch, you only expect
> that property to be added, not that the file to be updated to that
> revision of the original repo. And that property could be something like
> "this is a word document" and maybe is not true, but is a possibility
> that the user should take care, not the system.
You're talking about separating the 'property diff' from the
'content diff'.. ? Not sure that makes sense, as the 'file' consists
of both content and properties. I'd argue if you are in that situation
then the original commit should have been two commits instead (one for
the content, another for the properties). This is the "You can't merge
in changes with more granularity than the original commits" problem.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 19 16:45:27 2004