View Ticket
Ticket Hash: e29ea5912afe1e97149ad181dc898bc7bbaa6237
Title: Privacy attribution loss due to de/reconstruct ...
Status: Fixed Type: Code_Defect
Severity: Severe Priority:
Subsystem: Resolution: Fixed
Last Modified: 2010-11-24 21:33:07
Version Found In: 115f3ea60e
As I also use Git in our company to communicate with Subversion used at work, I liked the fact, that I can work locally, change the commit and comments and if all is finish, I can checkin to the central repository.

Now I intent to use Fossil's privat branches the same way. I intend to make my own checkins locally and if I am finished I send all with a big checkin to my central repository by merging the private branch into a non-private one to get it pushed later on.

So far so good. As I investigated the possibility to implement a feature in Fossil to get private branches pushed as well (but not synced or pulled) for backup purposes, I stumbled over the fact, that private branches lose its privacy attribution, if I deconstruct (with following reconstruction) a repository.

What makes it worse is, that if I look at the reconstructed repository the private branch looks exactly like at the original repository. I cannot determine, it is not private any longer. Therefore it will be cloned and synced as well ...

I will attach a small shell script to show the bug ...

Best regards, chi.

anonymous claiming to be Joerg Sonnenberger added on 2010-11-18 22:47:06:
This is partially by design. Private / public is not a property in the manifest and can't survive a deconstruct as such.

It would be useful for this kind of situation to be able to edit the property afterward, but it seems like the normal edit can't do that ATM?

chi added on 2010-11-19 12:00:41:
You mean "by design"? I thought, it was by accident ...

I feel the behavior not correct. I mean reconstructing a repository should result in the same repository afterwards. Otherwise it would be a destroying operation. Of course, your idea to edit a branch to make it private after the fact (or remove privacy afterwards) would be a nice add-on too. But for reconstruction, I feel the privacy should survive. If we could have some card within a manifest to mark privacy, this could also be used to allow to push private branches to other repositories as well.

Then we could use the push mechanism to allow incremental backup of Fossil repositories to another server without copying the whole repository all the time again and again ...

anonymous claiming to be Joerg Sonnenberger added on 2010-11-19 12:10:46:
deconstruct / reconstruct only preserve persistent data, e.g. the manifests and linked entries. The "private" flag is (intentionally) not persistent as it would prevent publishing the changes later.