File Sharing and Revision Tracking

[Madison]

Okay, so.

Each file has certain relevant characteristics associated with it.

They are;

• file name - this should be created by the site based on given information. i.e., "InventorFile(Jon060303).idw" or something. This will prevent overwriting important files on a person's hard drive.
• file extension - likely included in the file name. it otherwise wouldn't need to be displayed.
• file size - self-explanatory, I'd guess.
• description - a brief description of what the file is or contains.
• date created - the date the file was created/uploaded. Is there a difference? Should there be?
• last revision - The date of the most recent "promotion." for the file. I'll get to what a promotion is in a bit.
• created by - The user that created the file originally.
• revised by - The last user who's revision was "promoted."
• checked out by - which user has checked the file out for use.
• due back by - when to expect that user to be finished and the file to be checked back in.
• project association - which project the file belongs to. this doesn't need to be displayed.
• subgroup association - which subgroup within a project the file belongs to. this doesn't need to be displayed.

With these characteristics, users and administrators should be able to learn as much about a file as they'll need to know.

There needs to be some file tracking and a hierarchy. For this, there are five primary functions, and within each of those, there may be secondary functions.

• download - download selected file or files. here, a user is given the option to "check out" one or more of those files, indicating they'll be making changes to them and causing their username to appear in the initial file information as outlined above. "checking out" a file requires that a user decide to lock the file or not, prohibiting further downloads, as well as that they indicate when they expect to return the file. If a file is currently checked out, a message will indicate this, or that said file is "locked."
• upload - upload files from a users offline or online storage device. here, users can choose to "check in" a file if they currently have it checked out. if a file is "checked in" it overwrite the master file. if the file isn't checked in, or is being uploaded by someone without possession of that file, a "pending" group is created below the master file.
• promote - used to change the status of a "pending" revision to the master file. this will overwrite the master file.
• demote - used to change the status of a master file to "pending." this may result in there being no master file. this is useful because a group may want to keep the old master file on hand.
• delete - delete a file from the exchange

This methodology combines locking a file from use and keeping all revisions and changes available. By giving a user the ability to check out a file, it provides a way to indicate that changes are being made, but it doesn't prevent others from examining the files on their own, and possibly suggesting changes. It's likely best that certain functions, such as a promote, demote, and delete are only available to certain users. My user control panel features a similar promotion and demotion system.

Hopefully, by creating a list of pending changes to a file or files, it'll maintain the flexibility of multiple users working on the same project and file, but it'll still offer some degree of control over the changes, as well as preserve a bit more bandwidth and storage space.

How's that?