Hi Andy:
In message <5538e894-bdfa-ad31-be79-26383e8ea...@gmail.com>,
Andy Goth writes:
>On 5/14/2016 4:59 PM, John P. Rouillard wrote:
>> I had to recently shun some artifacts from a fossil repo (due
>> to embedded security credentials). Now when I look at the
>> fossil timeline that spans that shunning I no longer have a
>> single connected trunk.
>>
>> So is there some way to reintegrate the trunk across the shun?
>> Is this split timeline just a side-effect of shunning?
>
>Quite simply, you have a hole in your repository.
As I suspected, I removed a link in the middle of the timeline chain.
>To fix, you're going to have to go back to the version prior to
>the shun and redo every check-in since that point. Use the
>-date-override and -user-override commit options to make your
>commits resemble the originals. As far as I know, no one has
>scripted this kind of reconstruction yet, so you're on your own.
Fair enough. If I come up with a script I'll post it.
>A consequence is every manifest artifact ID since the shun will
>change. If you have any references to the old artifact IDs,
>e.g. in tickets or subsequent check-in comments, you may want to
>update them as well.
Fortunately there are no artifact references in
tickets/wiki/comments. But if there was, would some SQL magic
be needed to find/change these references?
>In retrospect, you would have been better off not shunning the entire
>check-in but rather only the file containing the security credentials.
That makes sense. What is the easiest way to get the artifact
ID for the file?
fossil timeline -v
gives you the file name, but not the artifact number. I would
have expected the artifact number as part of the listing:
[305556e6e5] fourth shunable commit (user: rouilj, tags: trunk)
EDITED 2 [artifact_ID]
Then I could "fossil what artifact_ID" to get the full sha1 sum.
It looks like I need to "fossil finfo 2" to get all artifacts for
all versions of the file named 2. Then I need to search the finfo
for the checkin artifact number to figure out which artifact I
need to wipe.
Is there an easier way?
[[ As a side note "fossil json timeline checkin -v" does have the
uuid's for the files in it. I am not sure parsing json is easier
even with tools like jq, but... ]]
The timeline view in the web interface also doesn't supply
artifact id's for the files created during a checkin. I am
thinking of something like:
[305556e6e5] fourth shunable commit (user: rouilj, tags: trunk)
EDITED 2 [artifact ID here] [diff]
If I had seen the artifact ID's, I would most likely not have
shunned he checkin and shunned the files instead 8-(. I would
still have to click on the file names to get the whole sha1
artifact number for shunning but it would have made me think twice.
Might it make sense to add a verification step if any of the
shunned artifacts are a commit record since this misstep is a
pain to recover from?
>Then do a check-in that corrects or removes the file.
There was a following checkin that fixed the issue before I
shunned the earlier versions with the credentials.
>It is legal, though certainly not ideal, to have one or more
>manifests refer to artifacts not present in the repository.
>Fossil's handling of this situation isn't quite as graceful as
>it could be, but I don't think it's going to outright die.
Doesn't seem to have died.
In my test case repo, accessing the artifact by UUID returns an
unknown page notice in the web interface. Accessing the artifact
with "fossil artifact" again just reports not found.
Looking at the commit the diff (and mlink) table report that the
shunned artifact is deleted. "timeline -v" shows:
21:15:19 [305556e6e5] fourth shunable commit (user: rouilj tags: trunk)
DELETED 2
and "fossil finfo 2" doesn't show a fourth commit at all.
Looking at the timeline (with file listing) in the web ui, I do
see a (deleted) notation on the shunned file and a subsequent
(new) notation on the following revision. So a little misleading
but amending the checkin comment can explain it away, so not a
real issue.
Looks like the missing artifact is being handled reasonably.
Also it looks like you must support manifests with missing
artifacts otherwise shunning can't work at all. As it always
leaves references to missing artifacts (the commit record) if
nowhere else.
>> Would doing a fossil git-export | fossil git-import "fix" things?
>No, nor would a rebuild, nor would a deconstruct followed by a
>reconstruct.
Right because I deleted the commit artifact needed to stitch
the commits before and after the shunned commit together.
Thanks for your feedback.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
