Conflict management in a versioned file system

• US 8,214,410 B2
• Filed: 04/20/2011
• Issued: 07/03/2012
• Est. Priority Date: 04/18/2007
• Status: Active Grant

• Current Assignee: SAP SE
• Original Assignee: SAP AG (SAP SE)
• Inventors: Sohn, Matthias E., Halstrick, Christian K., Zivkov, Sasa, Kempin, Edwin, Hiranniah, Girish B.
• Primary Examiner(s): LU, KUEN S
• Application Number:
  US13/090,764
• Publication Number:
  US 20110196847A1
• Time in Patent Office: 440 Days
• Field of Search: None
• US Class Current: 707/809
• CPC Class Codes: G06F 16/1787 Details of non-transparently synchronising file systems
• CPC Class Codes: G06F 16/1873 Versioning file systems, temporal file systems, e.g. file system supporting different historic versions of files

Abstract

Multiple files in a versioned file system are grouped to form a fusion unit on a server. The fusion unit is exposed to a client as a browsable folder having separate files. When the server receives an indication of a change to file belonging to the fusion unit, the server determines whether the change to the file causes a conflict on the fusion unit. If the change does cause a conflict, then the conflict is reported; otherwise the fusion unit is updated to incorporate the change.

Claims

1. A system comprising:

a server accessible by a client over a network, the server operable to;

group a plurality of files as a single version unit to form a fusion unit on the server;

expose the fusion unit to the client as a browsable folder having separate files;

receive an indication of a change to a file belonging to the fusion unit;

determine whether the indicated change to the file causes a conflict for the fusion unit; and

report the conflict for the fusion unit if the indicated change to the file causes the conflict for the fusion unit, else update the fusion unit on the server to incorporate the indicated change to the file; and

a storage unit, coupled to the server, to store the fusion unit.

2. The system of claim 1, wherein the conflict can only exist for the fusion unit.

3. The system of claim 1, wherein if the change to the file causes a conflict, the server to reconcile the conflict with the fusion unit based at least in part on a conflict resolution policy.

4. The system of claim 1, wherein the server is a design time repository (DTR) server.

5. The system of claim 1, wherein the server is operable to manage storage space of the storage unit by storing only the change to the file in the fusion unit.

6. The system of claim 1, wherein the server to update the fusion unit to incorporate the change to the file by storing a new version of each fusion unit file in the storage unit, including the changed file.

7. The system of claim 1, wherein the server is further operable to:

receive a request from the client to check-out the file belonging to the fusion unit;

generate a working copy of the fusion unit in response to the request; and

notify the client of the working copy.

8. The system of claim 7, wherein the server is operable to:

receive a changed copy of the file from the client;

determine whether the changed copy of the file conflicts with the working copy of the fusion unit; and

report any conflicts between the changed copy of the file and the working copy of the fusion unit.

9. The system of claim 1, wherein the server is further operable to maintain a database to track metadata.

10. The system of claim 9, wherein the metadata comprises:

change logs, timestamps, and user permissions.

11. The system of claim 1, wherein the client comprises a local storage unit to store a copy of a portion of contents stored in the storage unit coupled to the server.

12. The system of claim 11, wherein the client is operable to sync the contents of the local storage unit with the contents stored in the storage unit coupled to the server.

13. The system of claim 12, wherein the synced contents are read-only contents until the contents are checked-out.

14. The system of claim 1, wherein the server is operable to allow the client to check-out the fusion unit in response to receiving a request from the client to check-out the file.

15. The system of claim 1, wherein the server is operable to provide a version history for a file belonging to the fusion unit in response to a version history request from the client.

16. The system of claim 1, wherein the server is operable to lock the file against check-out until the file is checked-in.

17. The system of claim 1, wherein the server is operable to generate a new version of the fusion unit in response to deleting a member of the fusion unit.