Martin Langhoff <[EMAIL PROTECTED]> writes: [...]
> The problem with "expecting the scm to deal with renames" is that > most SCMs have a very naive implementation, trying to catch renames > and similar operations at _commit_ time. That's putting the smarts > in the wrong place. I think you're confusing two aspects. Some SCMs try to guess renames, but most don't. In Mercurial, I can say "hg rename", and it doesn't need to guess anything. There's complexity if you also want to support copy (as subversion seems to, for example). In that case it's tempting to regard rename as copy+delete, but I'm not sure that that all works out right semantically. Rename on its own seems a relatively coherent notion, though? It seems like information that users can sensibly give an SCM, and that an SCM can make use of. If git (or any other system) doesn't *record* renames, then that feels like a mistake; I can completely understand why git might not attempt to use renames in any way (leaving that to cogito or other front-ends). [...] > + one of those merges deals with renames: if a target file in the > patch isn't there, it walks up the commit history trying to find the > commit where we last saw a file with that name, and then analyses > that particular commit to detect the rename Right, and *that* sounds like it's trying to be too smart. Depends how it gets patches, I guess. If you need to receive raw patches which don't explicitly indicate renames, then it's good to try inferring them. That seems like an important usage for most people. But for projects working largely within a system, that feels unnecessarily like guesswork. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
