On Mon, Nov 10, 2014 at 11:46 AM, Jan Nijtmans <jan.nijtm...@gmail.com> wrote:
> Commit 70 moved everything under "/trunk/tkimg/" directly under "trunk". In > the same commit I added svn properties to other branches, so - indeed - > this is a challenging test-case..... I would expect this single svn commit > result in 5 separate fossil commits, all with the same "svn-rev-70" tag > (fossil doesn't have problem giving the same tag to multiple commits). > One commit handles all changes in trunk, one commit handles all > changes in the "img-base" branch, and then 3 remaining commits > handling tags "img-1.2.4", "img-1-3" and "img-1-3-rc2". Those > latter 3 should all become branches in fossil, I guess. Here is my proposal on how to handle these (and other) weird cases: Note - all this is only if not using the --flat flag. If using it, these problems don't arise. Any changes done outside of the trunk/branches/tags directories will be ignored (silently or with a warning) A branch/tag that doesn't have an obvious parent checkin to apply to, will be applied to the most recent checkin (or should it be the most recent one on the trunk?) If a single commit has multiple tags/branches/trunk changes, they will each get recorded separately, but with the same timestamp and svn-revision-NNN tag. If a change is made to a file under the tags directory, or a file is added/deleted, the commit that it tagged will be forked (or should it branch?) and a new commit with the changes will be added and tagged. If a branch is deleted, it will be marked as closed. If the trunk is deleted, the whole thing will fail. I don't know how to manage deleted tags. How does that sound? If it is all right, it will still take a few days to put this together. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
_______________________________________________ fossil-dev mailing list fossil-dev@lists.fossil-scm.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev
