On Fri, Jan 22, 2010 at 01:43:51PM +0100, Stefan Sperling wrote:
> On Fri, Jan 22, 2010 at 12:12:26PM +0100, Daniel Näslund wrote:
> > Local add, incoming add
> > -------------------------
> > THEIRS: Put new BASE file/dir in WORKING.
> > MINE: Keep current WORKING file/dir.
>
> In the MINE case, what do you do with the file in BASE which
> the update just brought in? It needs to be deleted because it
> already exists at HEAD in the repository. I think we want
> the WORKING file to replace the file in BASE if the user
> picks the MINE option. Correct?
>
> > RENAME-MINE:
> > Move WORKING file/dir to <user-suggest>. Replace WORKING
> > file/dir with the BASE-TARGET file/dir.
>
> The file is already added (or maybe even "added with history" in
> wc1 terms). So rather than "moving the added WORKING file",
> we may want to phrase this as "adding the WORKING file at a
> different location".
>
> > MERGE Merge BASE file1 onto WORKING file2.
> > ### There may exist copyfrom info and it may not. How handle the
> > ### different cases?
>
> If any copyfrom info is present (i.e. at least one of the files
> was copied), the user needs to select a copyfrom source:
>
> WORKING file | BASE file | Options
> has copyfrom | has copyfrom |
> Yes Yes Pick one copyfrom of 2, or none.
> Yes No Use WORKING copyfrom, or none.
> No Yes Use BASE copyfrom, or none.
I haven't grasped how copyfrom works. As I understatand, the repository
knows how to track copies and renames but 'svn up' fails to transmit
that information [1]. If so then copyfrom information in the client
should only be relevant for for the current uncommited work, what is
known as the WORKING tree.
If I look in wc-metadata.sql I see that there is fields in WORKING_NODE
for copy_from and moved_here but no such fields for BASE_NODE. When I
spoke to Julian about this on IRC, he said the concepts of working and
base in wc-1 does not map directly to the concepts in WC-NG db.
The question: How can a BASE file have copyfrom information?
cheers,
Daniel
[1] http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.moves
Received on 2010-02-08 15:15:11 CET