Re: [RFC] Target aware commit message processing

On Wed, Apr 23, 2008 at 10:20:58PM -0500, Troy Curtis Jr wrote:
> Also there is the case of moves. They are modeled as a copy-with-history and
> delete. With this feature you could potentially delete the 'deletion' part of
> the operation leaving only the copy, which is a significantly different
> operation. And after the commit is done, you are still left with a scheduled
> deletion. Maybe this is fine, after all you can already do it manually by
> specifying the copied file during a commit. But it is a little different.
> You are no longer just 'omitting' a change. Really the change is a
> 'move' which
> you turned into a 'copy', (possibly) followed by a 'delete' somewhere down the
> road.

Ouch, that rename thing *again*.

For now, you could look at the copy source (copies have 'copied-from'
pointers in the working copy), and check if the copy source
was deleted. Then add special markers to both files, like this:

        A+ new (probably moved here from 'old')
        D old (probably moved to 'new')

(A+ is 'add-with-history')

Note the word 'probably'. You can't be certain, because
the user might have deleted 'old', replaced it with something
else entirely, and then renamed the new thing.

wc-ng will hopefully make this easier to deal with.

-- 
Stefan Sperling <stsp_at_elego.de>                    Software Monkey
 
German law requires the following banner :(
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                               CEO: Olaf Wagner
 
Store password unencrypted (yes/no)? No