Method and apparatus for storing changes to file attributes without having to store an additional copy of the file contents

Abstract

A method of and an apparatus for storing changes to file attributes without having to store an additional copy of the file contents. In a system for maintaining and making changes to content for a website, extranet site or intranet site, memory may be allocated as a backing store. Preferably, the contents of the backing store are saved despite a shutdown or power failure. Information may be stored by the backing store in the form of files, each file including contents and attributes. The content of a file includes the information stored within the file, while the attributes of the file include information relating to the file. When a change is made to the file contents, both the changed version and the version prior to the changes may be stored in the backing store. For each version of the file contents, associated attributes are also stored. However, when a change is made to the attributes of the file without a change to its contents, the newly changed attributes may be stored in the backing store along with the prior version of the attributes. The newly changed attributes and the prior version of the attributes then share the same version of the file contents. By avoiding having to store multiple versions of the file contents, storage space in the backing store is preserved. A pointer may be provided in the backing store which links both the newly changed attributes and the prior attributes to the same copy of the associated file contents.

Description

RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 60/192,244, filed Mar. 22, 2000. U.S. patent application Ser. No. ______ , filed on the same day as this application, and entitled, “Method Of And Apparatus For Recovery Of In-Progress Changes Made In A Software Application,” and U.S. patent application Ser. No. ______ , filed on the same day as this application, and entitled, “Method And Apparatus For Automatically Deploying Data In A Computer Network,” are hereby incorporated by reference.

FIELD OF THE INVENTION

[0002] The invention relates to management of memory resources. More particularly, the invention relates to management of memory resources utilized during development of content for a website, extranet site or intranet site.

BACKGROUND OF THE INVENTION

[0003] Data is typically stored in a computer system in the form of data files. A data file may include content and identifying information and may change over time in response to a variety of events. For example, a file may be named, re-named, moved, copied, updated, supplemented, edited or deleted. Thus, the content of a data file or its identifying information may each be altered several times during the course of events. Particularly, for development of a website, extranet site or intranet site, a large quantity of information may need to be stored and may need to be frequently altered. For example, storage may be required for work-in-progress and published editions of the website, extranet site or intranet site.

[0004] In computer systems that manage large quantities of data, it is often desirable to keep track of changes to files. This is typically accomplished by storing a prior version of a file and a new version of the file in computer memory each time the file is changed. This storing of file versions can be especially useful in the field of website development where it may often be necessary to revert to a prior version of the website or a portion thereof. A drawback to this technique, however, is that a large amount of physical computer memory can be required to store the various different versions of the files that make up the website.

[0005] While the cost of computer memory has generally been decreasing, communication bandwidth has increasingly become a limiting factor in computer systems. Thus, there has been little incentive to reduce the amount of memory required for data storage except to the extent that bandwidth-reducing techniques, such as file compression, also incidentally reduce memory requirements. However, file compression has a disadvantage of requiring additional processing capability to compress and decompress the files. Further, file compression techniques are generally tailored specifically to the type of data contained in the file and are, thus, not universally applicable.

[0006] Therefore, what is needed is a technique for minimizing the amount of physical memory required for storing various different versions of changed files. More particularly, what is needed is a technique for minimizing the amount of physical memory required for storing various different versions of a file generated during development of a website, extranet site or intranet site. It is toward these ends that the present invention is directed.

SUMMARY OF THE INVENTION

[0007] The invention is a method of and an apparatus for storing changes to file attributes without having to store an additional copy of the file contents.

[0008] In a computer system that manages a quantity of data, the data is stored in computer memory in form of files. For example, in a system for maintaining and making changes to content for a website, extranet site or intranet site, physical memory may be allocated for work areas, staging areas and edition areas. Work areas may store in-progress changes to be made to the content by an individual contributor or group of contributors. Once the changes are made in the work areas, the changed content may be submitted to a staging area or areas. In the staging area, the content changes may be combined. From the staging area, the changed content may be forwarded to an edition area or areas. The edition areas may store versions or editions of the content for the website, extranet site or intranet site.

[0009] In addition to the memory that may be allocated for the various purposes described above, a physical backing store memory may also be provided for providing persistent storage for changes and other content. By persistent, what is meant is that the contents of the backing store are preferably saved despite a shutdown or power failure occurring to the system of which the backing store is a part.

[0010] Because the website, extranet site or intranet site may allow access to a large quantity of data, including, for example, text, graphics and audio information, the backing store memory may need to store a large quantity of data. This especially true considering that the backing store may store work-in-progress and multiple editions or versions of content for the website, extranet site or intranet site. For example, the backing store memory may be required store up to three times or more the size of the entire content of the website, extranet site or intranet site.

[0011] Files in the backing store or other memory each include contents and attributes. The contents of a file include the information stored within the file. This may include, for example, the text, graphics and audio information which is to be accessible via the website, extranet site or intranet site. The attributes of a file (the attributes may also be referred to as “metadata”) include information relating to the file. This may include, for example, the size of the file contents, a time stamp indicating when the file was created or when the file contents were last changed, an identification of an owner who is the contributor responsible for the file, an identification of a group to which the file or its owner belongs and permission information for restricting access to the file for performing read and write operations on the file.

[0012] The attributes of a file are stored, such as in the backing store, in association with the contents for the file. When a change is made to the file contents, both the changed version of the file contents and the version prior to the changes may be stored in the backing store. For each version of the file contents, associated attributes are also stored. Because the attributes may include the size of the file and a time stamp indicating when the file was last changed, changes in the file contents generally result in changes to the attributes. Accordingly, a different set of attributes is stored for each version of t he file contents.

[0013] However, when a change is made to the attributes of the file without a change to the contents of the file, the newly changed attributes may be stored, such as in the backing store, along with the prior version of the attributes. The newly changed attributes and the prior version of the attributes then share the same version of the file contents. In this way, multiple versions of attributes may be associated with a single copy of file contents. Thus, storage space in the backing store is preserved since storage of a separate copy of the file contents in association with each version of the file attributes is avoided. A pointer may be provided, such as in the backing store, which links both the newly changed attributes and the prior attributes to the same copy of the associated file contents.

[0014] The present invention is particularly advantageous for reducing the amount of storage space required in a system for development of a website, extranet site or intranet site. This is due, at least in part, to the large quantity of data files generally required to be stored in such systems and the need to store prior versions of files along with new versions of the files.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] FIG. 1 illustrates a computer network system for website development in accordance with the present invention;

[0016] FIG. 2 illustrates diagrammatically a work area, a staging area and an edition area, which may be utilized by the system of FIG. 1;

[0017] FIG. 3 illustrates diagrammatically computer memory, such as the backing store memory of FIG. 1, for storing files having attributes and contents in accordance with the present invention;

[0018] FIG. 4 illustrates diagrammatically a file, which is undergoing development stored in the backing store memory of FIGS. 1 and 3;

[0019] FIG. 5 illustrates diagrammatically files stored in the backing store memory as a result of making a change to the contents of the file of FIG. 4;

[0020] FIG. 6 illustrates diagrammatically contents of the backing store memory as a result of making a change to the attributes of the file of FIG. 4;

[0021] FIG. 7 illustrates diagrammatically contents of the backing store memory as a result of making another change to the attributes of the file of FIG. 6; and

[0022] FIG. 8 illustrates diagrammatically contents of the backing store memory as a result of making a change to file contents associated with one of the sets of attributes of FIG. 7.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

[0023] FIG. 1 illustrates a computer network system 100 for website development. On development workstations 102, website developers may add, remove, edit and examine files for a website. Development workstations 102 may include conventional personal computers, UNIX workstations, or other workstations that can be configured to develop content. The development workstations 102 may be connected to a development server 104 via a computer network 106, such as the Internet or a local area network (LAN).

[0024] The development server 104 includes a web server 108 for serving up content to web browsers, and a backing store 110 for storing versions of website content. The server 108 processes hypertext transfer protocol (HTTP) requests from the development stations 102 for website content (e.g., files). The website files may be physically stored in the backing store 110 which may be conventional, such as the WINDOWS NT files system commercially available from Microsoft Corporation.

[0025] The development server 104 may also include a conventional memory 112 (e.g., RAM) and a conventional processor 114, which implements the website development methods of the present invention by executing software 116 stored in the memory 112. An HTTP protocol virtualization module 118 which the processor 114 executes to allow web server 108 to operate as if it were multiple servers may also be stored in the memory 112.

[0026] The development server 104 may be coupled to a website production web server 120 via a network 122. Network 122 may be the same network as network 106 or a different network. The web server 120 may also be coupled to the Internet or an intranet 124. When a website is ready to be posted on the World Wide Web or on an intranet, the development server 104 sends the website content to the production web server 120 which then provides Internet or intranet access to the website.

[0027] A website is generally comprised of the contents of an arbitrary file system. The website development system 100 of the present invention may include hierarchical file systems. Each such file system of the present invention provides an environment for managing and manipulating individual files. When executed, the website development software 116 part of the file system enables the management and manipulation of files. The backing store 110 is where the files and corresponding metadata (e.g., owner identification, group identification, access control, file name, modification times, creation times, etc.) may be physically stored.

[0028] A hierarchical file system of the present invention may be referred to as an “area.” There may be different types of areas including work areas, staging areas and edition areas. A work area is typically a modifiable file system that is used by persons who create and maintain web content for eventual use in a website.

[0029] Memory may be divided into areas utilized for different purposes. For example, FIG. 2 illustrates diagrammatically a work area 200, a staging area 202 and an edition area 204. Though a single work area 200, staging area 202 and edition area 204 are illustrated in FIG. 2, it will be understood that plural work areas, staging areas and edition areas may be provided. Files 302-316 (FIG. 3) may be created or modified in the work area 200. For example, each individual contributor may be assigned a work area, such as the work area 200. Alternately, a group of contributors may be assigned a work area. In addition, the work area 200 may include a physical memory device which is distinct from memory devices utilized for the staging area 202, the edition area 204 or the backing store memory 110 (FIG. 1). For example, the work area 200 may include memory of an individual contributor's personal computer system.

[0030] The staging area 202 is usually an area where content is assembled before it is published. Since the work areas 200 are generally areas for creating and maintaining content exclusively, the staging area 202 (and the edition area 204), may be restricted to only assembling and displaying content. By design then, the staging 202 and edition 204 areas may be configured as read-only file systems. Any modifications to content may then be sent from an editor back to a workstation to perform any changes that may be needed. Thus, a task for which content is modified may reference content in a staging 202 or edition area 204 but with the modifications actually taking place in a work area 200. This helps to maintain the integrity of the content and to simplify the process. However, a business may want the system 100 to be more flexible, allowing other people such as editors to modify the content directly before it is published. The staging and edition areas may then be configured as modifiable file systems. Thus, in such an embodiment, content submitted from work areas may be edited in a staging area 202 or in an edition area 204.

[0031] A work area 200 may initially include a virtual copy of an entire website (unless there is no existing website, in which case the work area may be empty). In other words, a work area 200 may initially have the same contents as the file system designated as the website. A work area 200 provides a developer's personal view of a website in which the developer may contribute to the website. For example, in a work area 200, developers can freely add, delete and modify website content and see how their changes fit into the context of the entire website. Changes made by developers in work areas preferably do not affect the website or the work of other contributors in other work areas. This is because each work area may be a separate file system. Typically, a work area is located at a workstation 102 (FIG. 1).

[0032] Developers may integrate their work in a staging area by submitting the contents of their work areas 200 into a staging area 202. The staging area 202 is a file system available to multiple developers that provides a shared view of the website. Thus, a staging area 202 may hold the collective work of several developers' work areas 200 and may allow the developers to share and integrate their changes. In a staging area 202, the developers can see how their changes fit together. The staging area is typically located at the development server 104.

[0033] Copying is said to be “virtual” where areas share directory trees such that the directory trees do not have to be physically copied. The collective work in a staging area 202 changes as different contributors submit new content from work areas 200. Work areas 200 are most effective when the content and other information in the staging area 202 is virtually copied back to one or more private work areas 200. This helps to keep the individual work areas 200 up-to-date with respect to the staging area 202 while contributors are performing website related tasks such as creating and maintaining content.

[0034] When the collective work in a staging area 202 is deemed final, its contents can be published to create an edition of the website. This may be accomplished by virtually copying contents of a staging area 202 onto an edition area 204. Because an edition is typically a read-only file system, it is a frozen snapshot of the content of the entire website. Each edition taken at sequential points in the development of a website may be archived and accessible to all developers so that developers may instantly recall files, entire directories, or reconstruct entire past versions of the website. For example, the contents of an edition may be virtually copied into a work area to be used as a basis for further development of the website. An edition area 204 is typically located in the development server 104. Content (e.g., an edition) in the development server 104 may be deployed to the production server 120.

[0035] In sum, once changes are made to a file in the work area 200, the changed file may be submitted to the staging area 202. The staging area 202 may be utilized for combining changes to files made by various contributors in various different work areas 204. Once the changes are combined in the staging area 202, the changed files may be deployed to the edition area 204. The edition area 204 may be utilized for storing versions or editions of the content for the website, extranet site or intranet site.

[0036] During this process of making changes, combining and, then, deploying them, the contents of the work area 200, staging area 202 and edition area 204 may be stored in the backing store 110 (FIG. 1). For example, once a change made in a work area 200 is submitted to the staging area 202, the change may be stored in the backing store 110.

[0037] FIG. 3 illustrates diagrammatically a physical computer memory storing files in accordance with the present invention. In a preferred embodiment, the memory serves as the backing store memory 110 in the system 100 (FIG. 1) for website, extranet site or intranet development. Referring to FIG. 3, the memory 110 stores files 302-316, each file having attributes and contents. Thus, the file 302 includes attributes F01 stored in association with contents F01-1; the file 304 includes attributes F02 stored in association with contents F02-1; the file 306 includes attributes F03 stored in association with contents F03-1; the file 308 includes attributes F04 stored in association with contents F04-1; the file 310 includes attributes F05 stored in association with contents F05-1; the file 312 includes attributes F06 stored in association with attributes F06-1; the file 314 includes attributes F07 stored in association with contents F07-1; and the file 316 includes attributes F08 stored in association with contents F08-1. It will be understood that the memory 110 may form a portion of a conventional computer system or network, including, for example, one or more general purpose processors, software for controlling processor operation, and input/output devices for providing communication among the processors and external devices.

[0038] The contents of each of the files 302-316 are the information stored within the file. Because the files 302-316 may be utilized for organizing data which is to be accessible via a website, extranet site or intranet site, the contents may include, text, graphic images, sounds, software scripts, and so forth. The attributes of the files 302-316 include information relating to each file. This may include, for example, the size of the file contents, a time stamp indicating when the file was created or when the file contents were last changed, an identification of an owner who is the contributor responsible for the file, an identification of a group to which the file or its owner belongs and permission information for restricting access to the file for performing read and write operations on the file.

[0039] FIG. 4 illustrates the file 302 stored in the backing store memory 110. The file 302 of FIG. 4 may be undergoing development. Thus, for example, a contributor to the website, extranet site or intranet site of which the file 302 is a part, may make an addition, deletion or change to the contents F01-1 of the file 302. These changes may be made in the work area 200 (FIG. 2) and, then, submitted to the staging area 202 (FIG. 2).

[0040] FIG. 5 illustrates diagrammatically files 302, 304 stored in the backing store memory 110 as a result of making a change to the contents F01-1 of the file 302 of FIG. 4. The contents F02-1 of the file 304 shown in FIG. 5 includes changes, which were made to the contents F01-1 of the file 302. Because the contents F01-1 of the file 302 were changed, the contents F01-1 of the file 302, are stored in the memory 110 along with the original version of the contents F02-1 of the file 304. For example, the file 304 may be created upon submission of the changes to the staging area 202 (FIG. 2).

[0041] Because the contents F01-1 of the file 302 were changed, this tends to require that the attributes F01 also be altered. For example, one of the attributes F01 (e.g., a size attribute) may indicate the size of the contents F01-1 of the file 302. In which case, a change to the contents F01-1 would likely result in a change to the size attribute. As another example, one of the attributes F01 (e.g., a time stamp attribute) may include a time stamp for the last alteration of the file contents F01-1. In which case, the time at which the contents F01-1 were changed would be reflected by that attribute. Accordingly, the attributes F02 of the file 304 may differ from the attributes F01 of the file 302. Thus, as shown in FIG. 5, each set of attributes F01 and F02 may be stored in the backing store memory 110 in association with the corresponding contents F01-1 and F02-1.

[0042] Thus, storage of the files 302, 304 in the memory 110 as a result of a change to the contents F01-1 of the file 302 has been described.

[0043] Under certain circumstances, however, it may be desired to make a change to the attributes of a file without making any changes to the file contents. For example, the file may be re-assigned to a new owner who is to become the contributor responsible for the file. In which case, the attribute (e.g., an owner attribute) that identifies the owner of the file may be changed without any corresponding change being made to the file contents.

[0044] If one or more of the attributes F01 of the file 302 is changed, rather than its contents F01-1, a separate copy of the contents F01-1 need not be stored along with the changed set of attributes. Rather, a single copy of the contents F01-1 may be shared by both the original set of attributes F01 and the changed set of the attributes F02. This is shown in FIG. 6, which illustrates diagrammatically contents of the backing store memory 110 as a result of making a change to the attributes F01 of the file 302 of FIG. 4.

[0045] When a change to the attributes F01 of the file 302 is made, such as in the work area 200 (FIG. 2), the change may then be submitted to the staging area 202. As shown in FIG. 6, upon submission of the change, a new set of attributes F02, which includes the changes made to the attributes F01, may be stored in the memory 110 along with the original set of attributes F01 and the original contents F01-1 of the file 302. In addition, a pointer 600 may be stored in the backing store memory 110.

[0046] The pointer 600 includes an indication that the attributes F02 are associated with the file contents F01-1. For example, when the attributes F02 are formed, an identification of the pointer 600, such as its memory address, may be included in the attributes F02. This associates the pointer 600 with the attributes F02. The pointer 600 may then identify the file contents F01-1. For example, the pointer 600 may include a starting address for the file contents F01-1. This associates the pointer 600 with the file contents F01-1.

[0047] As a result of utilizing the pointer 600 to associate the file contents F01-1 with the attributes F02, the file contents F01-1 are shared by both sets of attributes F01 and F02. Accordingly, this conserves space in the backing store memory 110 because there is no need to store a separate copy of the file contents F01-1 for each of the two sets of attributes F01 and F02.

[0048] If another change is then made to the file attributes F02 of FIG. 6, then a third set of attributes F03 may be formed. FIG. 7 illustrates diagrammatically contents of the backing store memory 110 as a result of making another change to the attributes F01 or F02 of the file 302 of FIG. 6. For example, if the attributes F02 are changed again, such as to re-assign the file 302 to yet another owner who is to become the contributor responsible for the file 302, then a new set of attributes F03 may be formed. For example, the set of attributes F03 may be formed upon submission of this change to the staging area 202 (FIG. 2). An identification of the pointer 600, such as its memory address, may also be included in the attributes F03. This associates the pointer 600 with the attributes F03 in addition to the pointer 600 being associated with the attributes F02. Accordingly, the attributes F01, F02 and F03 may all share the same file contents F01-1.

[0049] Rather than including an identification of the pointer 600 in the newly formed attributes F03, a new pointer (not shown) may be formed. In which case, the attributes F03 may include an identification of the newly formed pointer. If the newly formed pointer is to replace the pointer 600, the attributes F02 may also be modified to associate the attributes F02 with the newly formed pointer.

[0050] Thus, storage of the files 302 in the memory 110 as a result of a change to the attributes F01 of the file 302 has been described.

[0051] If, however, a change is then made to the file contents F01-1, but which change is intended to affect the contents associated with only one of the sets of attributes F01, F02, F03, of FIGS. 6 or 7, then sharing of the file contents F01-1 may be discontinued. For example, assume that a change or substitution is made to the file contents associated with the attributes F03 of FIG. 7, but which is not intended to change the file contents associated with the attributes F01 and F02. For example, the change may be made in the work area 200 (FIG. 2) and, then, submitted to the staging area 202 (FIG. 2).

[0052] As a result, a new file 308 may be formed, as shown in FIG. 8. The newly formed file 308 includes attributes F04 and contents F04-1. The attributes F04 may be the same as the attributes F03, assuming no attribute changes were made. However, the attributes F04 may be updated to reflect the changes in the file contents F04-1. For example, a time stamp or file size may need to be altered. The contents F04-1 include the changes made to the file contents F01-1. The attributes F03 may also be retained in the memory 110 in association with the contents F01-1 for the purpose of tracking these changes to the file 302.

[0053] In general, the invention may include the utilization of dedicated processors, webservers configured to receive and route browser requests, application servers, state servers and other types of computer processors configured to communicate amongst each other and that may be connected to one or more networks, including a Local Area Network (LAN), an intranet and the Internet. However, it will be appreciated by those skilled in the art, such implementation of such devices and systems are but few illustrations of the utility of the invention, and that the invention may have greater applicability and utility in many other applications where efficient routing and processing of data within one or more networks is involved. Equivalent structures embodying the invention could be configured for such applications without diverting from the spirit and scope of the invention. Although this embodiment is described and illustrated in the context of devices and systems for exchanging data among users of a computer system or network, the invention extends to other applications where similar features are useful. The invention may include personal computers, application servers, state servers or Internet webservers that are designed and implemented on a computer and may be connected to a network for communication with other computers to practice the invention. A system configured to operate according to the invention may include a plurality of personal computers connected to the Internet via individual modems or other communication means such as wireless communications.

[0054] The invention may also involve a number of functions to be performed by a computer processor, such as a microprocessor. The microprocessor may be a specialized or dedicated microprocessor that is configured to perform particular tasks by executing machine-readable software code that defines the particular tasks. The microprocessor may also be configured to operate and communicate with other devices such as direct memory access modules, memory storage devices, Internet related hardware, and other devices that relate to the transmission of data in accordance with the invention. The software code may be configured using software formats such as Java, C++, XML (Extensible Mark-up Language) and other languages that may be used to define functions that relate to operations of devices required to carry out the functional operations related to the invention. The code may be written in different forms and styles, many of which are known to those skilled in the art. Different code formats, code configurations, styles and forms of software programs and other means of configuring code to define the operations of a microprocessor in accordance with the invention will not depart from the spirit and scope of the invention, which is defined by the appended claims.

[0055] Within the different types of computers, such as computer servers, that utilize the invention, there exist different types of memory devices for storing and retrieving information while performing functions according to the invention. Cache memory devices are often included in such computers for use by the central processing unit as a convenient storage location for information that is frequently stored and retrieved. Similarly, a persistent memory is also frequently used with such computers for maintaining information that is frequently retrieved by a central processing unit, but that is not often altered within the persistent memory, unlike the cache memory. Main memory is also usually included for storing and retrieving larger amounts of information such as data and software applications configured to perform functions according to the invention when executed by the central processing unit. These memory devices may be configured as random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, and other memory storage devices that may be accessed by a central processing unit to store and retrieve information. The invention is not limited to any particular type of memory device, nor any commonly used protocol for storing and retrieving information to and from these memory devices respectively.

[0056] While the foregoing has been with reference to particular embodiments of the invention, it will be appreciated by those skilled in the art that changes in these embodiments may be made without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims.

Claims

1. A method of storing changes to an attribute of a file comprising steps of:

altering an attribute of a file, prior to said altering, the attribute being included in a prior set of attributes of the file stored in a memory device;

storing in the memory device a new set of attributes, said new set of attributes including the altered attribute;

storing in the memory device a single version of file contents; and

sharing the file contents by the prior set of attributes and the new set of attributes.

2. The method according to

claim 1, wherein said altering is performed in connection with the development of a website, extranet site or intranet site and wherein the file contents includes information which is to be accessible via the website, extranet site or intranet site.

3. The method according to

claim 2, wherein said altering is performed in a work area and further comprising submitting the altered attribute for storage in the memory device, the memory device being part of a development server.

4. The method according to

claim 1, further comprising forming a pointer in response to said altering the attribute wherein the pointer associates the new set of attributes with the file contents.

5. The method according to

claim 1, further comprising:

altering the file contents; and

discontinuing said sharing of the file contents in response to said altering of the file contents.

6. The method according to

claim 5, further comprising:

storing a new file contents, the new file contents including the file contents as altered by said altering the file contents.

7. The method according to

claim 5, further comprising retaining in the memory device the file contents, prior to being altered by said altering the file contents, in association with one of the prior set of attributes or the new set of attributes.

8. The method according to

claim 5, wherein said storing stores the new file contents in association with the new set of attributes when the file contents are accessed via the new set of attributes for performing said altering and further comprising updating the new set of attributes so as to reflect the changed file contents.

9. The method according to

claim 5, wherein said storing stores the new file contents in association with the prior set of attributes when the file contents are accessed via the prior set of attributes for performing said altering and further comprising updating the prior set of attributes so as to reflect the changed file contents.

10. The method according to

claim 1, further comprising:

altering an attribute of the new set of attributes thereby forming a third set of attributes;

sharing said file contents by the prior set of attributes, the new set of attributes and the third set of attributes.

11. The method according to

claim 10, further comprising forming a pointer in response to said altering an attribute wherein the pointer associates the new set of attributes and the third set of attributes with the file contents.

12. The method according to

claim 11, wherein the new set of attributes and the third set of attributes each includes an identification of the pointer.

13. The method according to

claim 10, further comprising:

forming a first pointer in response to said altering an attribute of the file, wherein the first pointer associates the new set of attributes with the file contents; and forming a second pointer in response said altering the attribute of the new set of attributes wherein the second pointer associates the third set of attributes with the file contents.

14. The method according to

claim 13, wherein the new set of attributes includes an identification of the first pointer and wherein the third set of attributes includes an identification of the second pointer.

15. An apparatus for storing changes to an attribute of a file, the apparatus having physical memory comprising:

a work area including a file undergoing development, the file having a prior set of attributes and file contents; and

a staging area for receiving an alteration made in the work area to an attribute of the prior set of attributes wherein in response to receiving the changed attribute, a new set of attributes is stored in the memory, the new set of attributes including the altered attribute and the file contents being shared by the prior set of attributes and the new set of attributes.

16. The apparatus according to

claim 15, further comprising an edition area for storing contents of a website, extranet site or intranet site and wherein the file contents includes information which is to be accessible via the website, extranet site or intranet site.

17. The apparatus according to

claim 15, wherein said memory further comprises a persistent backing store memory for storing the prior set of attributes, the new set of attributes and the shared file contents.

18. The apparatus according to

claim 15, further comprising a pointer stored in the memory for associating the new set of attributes with the file contents.

19. The apparatus according to

claim 15, wherein when an alteration is made to the file contents in the work area, the file contents are no longer shared by the prior set of attributes and the new set of attributes.

20. The apparatus according to

claim 19, wherein a new file contents, as altered by said alteration to the file contents, is stored in the memory.

21. The apparatus according to

claim 20, wherein the memory device stores the file contents, prior to being altered by said alteration to the file contents, in association with one of the prior set of attributes or the new set of attributes, said prior set of attributes or new set of attributes updated so as to reflect the changed file contents.