On Friday, July 20, 2012 4:25 PM, Stephan Beal wrote:
> Generally sounds like a good idea, but what happens to the copy?
> Fossil doesn't have the concept of "sub-repos" like /branches,
> /trunk, etc. Each branch is its own namespace overlaid on a single
> top-level checkout. i don't know if fossil can make much use of a
> cp as it exists in svn.
I have two particular use-cases which would benefit from a fully-
supported copy operation:
(1) A user wishes to split a large source file into two, uses copy to
link the second file to the common ancestor and makes the various
modifications to both files to remove from each the duplicate
code where required, and commits. The commit history for the
files can then show how the file forked.
(2) During development, a file is discarded as redundant but later
found to be useful; it can then be restored from its earlier
version, complete with revision history.
> The easiest way to get started writing a new command is to......
> [...snip...]
Thanks, I'll get started there.
> Feel free to post questions and whatnot.
Thank you ;o)
As it happens I do have a question. Inside the manifest file an F-card
can include an "old name" where this links to the parent check-in. My
limited testing suggests that for a copy in scenario (1) above, all
that is necessary is to use this "old name" field. The handling of it
inside the timeline is all that is necessary to complete this side.
So the following almost works:
$ fossil init A.fossil
$ mkdir A
$ cd A
$ fossil open ../A.fossil
$ echo 'This is a test file' > test
$ fossil add test
$ fossil commit -m 1
$
$ # Copy and modify files
$ cp test test2
$ sed -i 's/test //' test
$ sed -i 's/ file//' test2
$
$ # Simulate fossil cp test test2
$ fossil add test2
$ sqlite3 .fslckout
sqlite> update vfile set origname='test' where id=2;
sqlite> .exit
$
$ # And commit
$ fossil commit -m 2
This gives a working commit diff function (patch also is correct).
But the history for test2 (http://localhost:8080/finfo?name=test2)
would, in my opinion, benefit from having a "copied from test" line,
or similar, for complete clarity.
As for scenario (2), this also works:
$ fossil init B.fossil
$ mkdir B
$ cd B
$ fossil open ../B.fossil
$ echo 'This is a test file' > test
$ fossil add test
$ fossil commit -m 1
$ rm test
$ fossil rm test
$ fossil commit -m 2
$
$ # Simulate fossil cp --from 123456 test test
$ echo 'This is a test file' > test
$ fossil add test
$
$ # And commit
$ fossil commit -m 3
The history of the file looks very smart and correct, just how I'd
like it, although the check-in changes list could be tweaked a bit
to show that the file has been copied from a previous version.
However, if the copy is made to another file name (for example, the
original file name is already being used for another purpose), or
if the file is additionally modified prior to commit (e.g. to match
other external changes made since the file was deleted), the whole
history thing falls down.
My question, sorry it has taken so long to get to it, is, is my
simulation in the first example a valid approach, and for the
second example, would it not be necessary to augment the F-card
to include the uuid of the check-in from which the copy has been
made so that it can be found by the timeline functions? And
would such a change to the manifest file structure be acceptable?
Thanks for your time in guiding me!
Andy
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
