On 4/1/2015 3:21 AM, Vikrant Chaudhary wrote:
>> I'm thinking about how this could be used at my workplace. On some
>> projects we have shared computers called viewservers ("view" being a
>> ClearCase term) on which we create our sandboxes (again, CC term).
>> Switching to Fossil would mean each user getting his or her own copy of
>> the full repository which synchronizes with the master. Furthermore,
>> each user would need a separate copy for each viewserver because it's
>> best not to share SQLite databases through NFS. This will eat a LOT of
>> disk space.
>>
>> If users could somehow share repositories without copying them in full,
>> that would help a lot.
>
> You are probably thinking about a "shallow clone".You'll have to tell me what you mean by those words. > By "clone --cheap", I was thinking more along the lines of "ATTACH > DATABASE". I.e., collecting missing deltas from upstream db which is > attached to main db. Which also means that upstream repository must > exist on file-system (no http). The impression I get is that we're both talking about the local repository containing things not sync'ed upstream, for example private branches. > Truth is, I need to understand more about Fossil internals to make any > assertions on what is possible and what is not. This is a dramatic departure from the current design of Fossil which directly opens the repository file, which is an SQLite database. What you suggest would require frequent communication with the repository at the remote-url for doing many kinds of read operations. -- Andy Goth | <andrew.m.goth/at/gmail/dot/com>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
