Fossil

View Ticket
Login

View Ticket

2011-03-26
12:53 Fixed ticket [e24ec32b]: privateness not preserved plus 1 other change ... (artifact: f0a559f1 user: drh)
12:53
Add the --private option to the "fossil branch new" command. Give a default orange color to private branches created by "fossil branch new". If the new branch created by "fossil branch new" is off of a private branch, make the new branch private too. Ticket [e24ec32b1da5f8f5e4abe] ... (check-in: 2b337816 user: drh tags: trunk)
2011-03-23
20:15 Ticket [e24ec32b] privateness not preserved status still Open with 2 other changes ... (artifact: a828bbf2 user: anonymous)
20:08 Add attachment private_propagation.patch to ticket [e24ec32b] ... (artifact: 970efec0 user: anonymous)
2011-03-21
07:20 New ticket [e24ec32b] privateness not preserved. ... (artifact: 82bfb822 user: anonymous)

Ticket Hash: e24ec32b1da5f8f5e4abe3b1eed6899f8be6f4cc
Title: privateness not preserved
Status: Fixed Type: Code_Defect
Severity: Minor Priority:
Subsystem: Resolution: Fixed
Last Modified: 2011-03-26 12:53:57
Version Found In: 04ddad7ab8
Description:
When branching from a private branch via "fossil branch new newBranchName current" the resultant branch is now visible.

When doing the above this also pops up: "gpg: no default secret key: secret key not available gpg: out-770939853ADDB6FA703B: clearsign failed: secret key not available unable to sign manifest. continue (y/N)? y"

I've never touched the clearsign setting and as far as I know it defaults to off but just to make sure I turn it off locally and then globally and the clearsign prompt still pops up.

Now when you do a branch from a private branch via: "fossil commit --branch stillPrivate -m 'some message'". privateness is preserved.

Furthermore, Dr. Hipp in an email response regarding converting private branches to public that you could do "DELETE FROM private" and then a fossil rebuild and all your private branches will be public. I updated to versions of trunk from when he wrote the reply(Tue, 22 Feb 2011 03:37:18 -08) and this is indeed the case all private branches are then public. Version 04ddad7ab8 doesn't display the same behaviour. After the rebuild, the private table is again populated with artifacts representing the manifests from the private branches. Wondering if this unadvertised "dirty trick" just doesn't work anymore of if the rebuild process is doing something it shouldn't


anonymous added on 2011-03-23 20:15:49 UTC:
This patch seems to fix the problem with "fossil branch new" from a private checking not preserving said privateness. Also fixes the problem with being prompted for a key even though the clearsign option is defaulted to off.

Seems like the logic for cancelling propagating tags between checkin.c

db_prepare(&q, "SELECT tagname FROM tagxref, tag" " WHERE tagxref.rid=%d AND tagxref.tagid=tag.tagid" " AND tagtype==2 AND tagname GLOB 'sym-*'" " AND tagname!='sym-'||%Q" " ORDER BY tagname", vid, zBranch);

and branch.c

db_prepare(&q, "SELECT tagname FROM tagxref, tag" " WHERE tagxref.rid=%d AND tagxref.tagid=tag.tagid" " AND tagtype>0 AND tagname GLOB 'sym-*'" " ORDER BY tagname", rootid);

is a bit different. My sql is a bit rusty so i'm not sure if they accomplish the same things just in different manners.

Still not sure why "delete from private" and then a fossil rebuild still leaves artifacts in the private table.


Attachments: