Hi,
A couple of years ago, I developed a source control system - called
Evolver - for a company that hired me. The company made video-games, and
wanted a source control system that was powerful enough for developers,
yet very easy to use for the other kinds of users (mainly "artists").
Evolver worked exclusive on Windows/NTFS, but I guess most NTFS features
are also found in Unix-like systems.
Although subversion goes way beyond the system I developed, I do miss a
couple of things. I must admit I'm new to subversion, so some of these
might already be implemented.
- Automatic detection of renames and moves. Evolver used NTFS
object-identifiers and the change-journal to track this.
- No "cleanup" needed. Because the above, "cleanup" did not exist. All
possible changes allowed by the file system got tracked automatically.
The only "cleanup" needed was when a new file with the same name as a
deleted file was created. Although most of the time this issue was
handled internally by NTFS file tunneling, it could happen when software
moved a file with the same name across different volumes.
- Properly handling of "file with same name exists in working copy".
- Concept of "generated" files. When a conflict occured on these files,
they got deleted by default, because they can be re-generated. Of course
a build-system like SCONS that uses caching is much more suitable to
handle this, but this is not always usable with content creation tools
that often do not support batch / command-line support.
- Semi atomic updates. Using a method of file locking and renaming, and
update of a working folder either completely succeeded or failed.
Rollback after a failure was possible because a special naming scheme.
- No ".svn" folders. Evolver stored all information in extra NTFS
streams, removing clutter.
- The concept of a "unit". Currently, it is possible to commit just one
file, but doing this is a bit like hacking. Usually one works on a
"project" which is an atomic unit. Committing only a subset of changes
is dangerous because they cannot be tested, and this quickly converges
into a "but it works on my machine" situation. In Subversion a "unit"
would be just some parent directory that is always used when committing,
unless explicitly overriden.
- Dependencies to other units. A unit usually makes use of other units.
Changes in the dependencies must usually be committed at the same time.
- NTFS junctions and hardlinks. I've seen this in discussions but have
no idea what the current status is. We used junctions to dependencies,
so that all required files were located under a single project
directory. The problem is that Windows itself does not support
junctions/hardlinks (e.g. Windows Explorer does not understand them).
- Concept of automatic locking of files. Although subversion supports
locking now, it must still be performed manually? Evolver performed an
automatic lock as soon as a file was overwritten. After all, binary
files cannot be merged, and parallel evolution of such a files should be
prohibited as soon as possible. Binary files are evil, but they are very
common in content development systems (Adobe Flash, Autodesk 3D Studio
MAX, Adobe Photoshop, etc).
- Multiple branches in the same working folder. One directory could
contain assets for multiple branches at the same time. One just selects
the current branch, and commits/updates automatically pick a parent
branch for finding the "common/base" revision. I have a feeling
subversion supports this, but I haven't figured out yet how.
- Inter-branch locking. A binary file that lives in multiple branches
could be locked in all branches at the same time.
- By default, reverting a directory deletes local files in it. After
all, reverting restores the previous revision, and since the file did
not exist in the previous revision, its previous state is void.
- An experimental feature was "refactor friendly structured storage". So
instead of storing dumb source code, a DOM was stored instead, using
unique-object-identifiers instead of names to refer to symbols. So
basically, source control did not stop on the file level, but at the
object level. Merging was done on this tree, which eased extreme
programming and refactoring. For example, renaming a class was just one
change to the DOM in which the class was declared, although it might
change dozens of source text files that used it. This was never used
because it would also require different source code editors that work on
the symbolic level.
I hope this information was useful, although I'm not expecting to see
any of this in subversion soon, as you guys probably have really good
reasons not to have implemented these "features".
Cheers,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 15 12:22:51 2007