On 5/16/2016 9:53 AM, Warren Young wrote:
On May 14, 2016, at 4:35 AM, Stephan Beal <sgb...@googlemail.com> wrote:
But in svn, now that i think about it, cp is, in practice, only used for
branching.
...
If the SCM doesn’t remember that y.cpp was cloned from x.cpp....
Actually, a copy command would sometimes be nice when refactoring an
over-large module into several smaller modules, in that it would
preserve more history in a place where it might be sought later.
For extra credit, one might imagine an analysis something like the
existing annotate/blame features that allows a file that is fragmented
into several files to preserve only the history pertinent to the bits
that move to each fragment in that fragment. I have no clue what the UI
for such a feature should look like, however.
Personally, I usually just treat such copies (or fragments after a
refactor) as brand new, and get on with life. Tracking everything sounds
nice on paper, but I'm not sure it is actually worth the required effort.
That would require a backwards-incompatible change to the manifest format
Unless some clever trick can be invented that will let older versions of
fossil simply see such files as newly added at the time of the copy
while letting a new version also track the history across that event.
I'm not steeped enough in the manifest details to know what is possible
myself, however.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
