File Versioning Vs Repository Versioning
Page 1 of 1 • Share •
File Versioning Vs Repository Versioning
People who are familiar with popular version control tools like Clearcase, PVCS, VSS would have been surprised to have seen the new way of versioning adopted in tools like Subversion. As a person who is familiar with both the worlds, I couldn't help wondering at the base difference in the artifacts versioning. While tools like Clearcase, PVCS and VSS are based on File based versioning, the tools like subversion use Repository versioning. I have attempted here to put together both the concepts and probably open the debate on which is more advantageous to the user community.
Definitions
File based Versioning: Each file is versioned individuallly when checked-in. When a group of files is checked-in at one shot, each file gets a new/its own new version number. This concept is used in most of the popular version tools like Clearcase, PVCS and VSS. There are minor variations of this concept adopted in some tools. For example, Clearcase, apart from versioning the files, also supports versioning of Folders (to track file addition/deletion/file name changes).
Repository based Versioning: Files are not versioned individually when checked-in. Instead the entire repository (normally equivalent to a project) is versioned. When a group of file is checked-in at one shot, all the files carry the version number that's of the repository. Since the versioning is based on repository, changes made in the form of file addition, file deletion and file rename are captured automatically.
Advantages of Repository Based Versioning over File Based Versioing:
1. Each version of the repository is a snapshot of the project. There is no need to maintain a separate Baselining/Labelling structure
2. Picking up any repository version results in the complete set of the artifacts as of that version. So pick up any repository version and go for a full build (i.e. compile/package all the files and not necessarily the modifed ones)
3. Suits perfectly for a project in maintenance mode that always requires full build.
4. Obsoletes the need for labelling and Folder versioning.
Disadvantages of Repository Based Versioning over File Based Versioing:
1. When the project is in development phase, the developers are expected to check-in files at regular intervals. This results in too many versions being created. Imagine a project with 500 files and 20 developers. Each developer checks-in 5 files a day at different timing, You have got 5*2*20*60 = 12000 repository versions in 3 months time. Not sure how any CM administrator could manage it.
2. Extracting the differential artifacts between 2 baselines is very difficult. Most of the maintenance releases, require incremental deliverables i.e. only the differential artifacts since the previous release. Assume the first release is sent using repository version 10. And by the time the second release is ready, the number of repository versions has grown up to 15. A command to view the difference between the repository version 10 and 15 would provide the list of files modified/added/removed. But to extract (the contents of) this differential artifacts would require individually picking up the files from the respective repository version. i..e you need to pick up the files modified/added for version 11, Version 12, Version 13, Version 14 and Version 15 separately to get the differential artifacts. Again remember the list is easy to obtain but not the contents per-se. In cases where Incremental build is the order of the day, extracting the differential artifacts may become a nightmare.
Let's keep this debate on. Let me know your opinion on this.
Definitions
File based Versioning: Each file is versioned individuallly when checked-in. When a group of files is checked-in at one shot, each file gets a new/its own new version number. This concept is used in most of the popular version tools like Clearcase, PVCS and VSS. There are minor variations of this concept adopted in some tools. For example, Clearcase, apart from versioning the files, also supports versioning of Folders (to track file addition/deletion/file name changes).
Repository based Versioning: Files are not versioned individually when checked-in. Instead the entire repository (normally equivalent to a project) is versioned. When a group of file is checked-in at one shot, all the files carry the version number that's of the repository. Since the versioning is based on repository, changes made in the form of file addition, file deletion and file rename are captured automatically.
Advantages of Repository Based Versioning over File Based Versioing:
1. Each version of the repository is a snapshot of the project. There is no need to maintain a separate Baselining/Labelling structure
2. Picking up any repository version results in the complete set of the artifacts as of that version. So pick up any repository version and go for a full build (i.e. compile/package all the files and not necessarily the modifed ones)
3. Suits perfectly for a project in maintenance mode that always requires full build.
4. Obsoletes the need for labelling and Folder versioning.
Disadvantages of Repository Based Versioning over File Based Versioing:
1. When the project is in development phase, the developers are expected to check-in files at regular intervals. This results in too many versions being created. Imagine a project with 500 files and 20 developers. Each developer checks-in 5 files a day at different timing, You have got 5*2*20*60 = 12000 repository versions in 3 months time. Not sure how any CM administrator could manage it.
2. Extracting the differential artifacts between 2 baselines is very difficult. Most of the maintenance releases, require incremental deliverables i.e. only the differential artifacts since the previous release. Assume the first release is sent using repository version 10. And by the time the second release is ready, the number of repository versions has grown up to 15. A command to view the difference between the repository version 10 and 15 would provide the list of files modified/added/removed. But to extract (the contents of) this differential artifacts would require individually picking up the files from the respective repository version. i..e you need to pick up the files modified/added for version 11, Version 12, Version 13, Version 14 and Version 15 separately to get the differential artifacts. Again remember the list is easy to obtain but not the contents per-se. In cases where Incremental build is the order of the day, extracting the differential artifacts may become a nightmare.
Let's keep this debate on. Let me know your opinion on this.
Admin- Admin
- Posts: 24
Join date: 2008-08-22

Permissions of this forum:
You cannot reply to topics in this forum





