Hi All -
Here are some ideas that I thought would be useful features in
Subversion. Please feel free to comment on them and let me know
of your thoughts.
1) .svn/ directory locations
The current implementation of SVN has these directories
throughout the project workspace. While this is a natural
extension of the way CVS does things, it might be good to provide
an option that leaves the workspace with no meta-files or
meta-directories. There are other SCM tools that follow the
philosophy of a pristine project workspace. The advantage is
that a user can simply TAR the whole project instead of having to
explicitly run an 'export' command.
The .svn/ directory also has some user security issues associated
with it. If by accident, the user TARs the entire codebase, the
.svn/ directories are included along with their repository
meta-data. Exposure of this meta-data might be undesirable in
many situations, such as during code drops to a client.
Although SVN has an export utility, large codebases can pose a
problem in the following way: Suppose a time-consuming binary
build has been executed, and the user wishes to TAR the entire
tree with source and binary. The SVN export command is difficult
in this case, since the binaries were built in the project
workspace.
My proposal is as follows: add an option in the Subversion
client's config file called 'separate-meta'. Enabling this
option would cause SVN to do the following:
a) Upon checkout, it would create a mirrored directory tree in
~/.subversion (or in an equivalent location for Windows, etc)
with all of the meta-data directories. The project directories
are hashed so that they can be relocated after the fact.
For example:
/home/user/project/src
would have a corresponding
~/.subversion/HASH/src/.svn
b) The hashes are stored in the following file:
~/.subversion/meta
as simple key-value pairs:
/home/user/project=13f822ad83fd018d
c) When SVN is invoked, the ~/.subversion/meta file is loaded to
read the table of key/value pairs. If the current directory has
a match with any of the keys, the .svn/ directory and contents is
referenced from the separate directory.
d) Add a new command 'svn relocate OLD NEW' which will relocate a
workspace to a different location. All this does is to execute
an operating system 'cp; rm' on all of the files, and update the
~/.subversion/meta key for that project. The hash stays the
same, preserving the mirrored directory structure.
The change should be relatively seamless to the user and only
requires client-side modifications. Implementing it as an option
allows it to co-exist with the current method of storing ~/.svn,
while giving folks like myself the alternate functionality.
2) Explicit edit support
While SVN follows the CVS "always-writeable" model, there are
many SCM tools that use an "explicit edit" model for file
editing. This may seem cumbersome to some developers, but others
prefer this mode of operation.
I propose to add an option in the config file called
'explicit-edit' which would enable the following behavior:
a) Upon checkout or update, all files are read-only
b) 'svn edit FILE' causes the file to become read-write
c) 'svn status' prints out the same type of information as
current, except with an extra letter tag.
Let's say that the project has two files:
Makefile
README
The user does 'svn edit Makefile README' to tag both files as
editable. Then, the user edits Makefile to make a change, but
leaves README untouched.
Then, 'svn status' should have the following output:
M Makefile
U README
where 'M' means Modified (as current) and 'U' means Unmodified,
signifying that the file is read/write permissions, but has not
been changed.
d) 'svn revert FILE' should restore the file and change it back
to read-only status.
e) 'svn revert -u' should revert all files that have the 'U'
status.
This change also only requires client-side modifications.
Implementing it as an option allows it to co-exist with the
current method, while providing the additional functionalty
to those who desire it.
3) Editing of the commit list
When 'svn commit' is issued, a list of files appears in the
user's editor. At this point, if this is not the desired list of
files, it is cumbersome to back out and re-commit with the
correct list. It would be nice for SVN to allow the user to
simply delete files out of the commit list, directly in the
editor. Then, when the commit is executed, only the files
remaining would be submitted.
a) If all files are deleted, the commit is cancelled
b) Upon commit, if 'explicit-edit' is enabled from above, the
committed files are changed to read-only.
4) External diff utility
I'd like to add an option in the config file called 'external-diff'
which would point to an external diff program. I like to use
TkDiff, an open source graphical diff tool:
http://www.accurev.com/free/tkdiff/
I hereby volunteer to implement these features. Since they are
all client-side, I should be able to get up to speed relatively
quickly. If somebody could please point me to the procedure
required to get approval, I would most appreciate it.
Best Regards,
Kumaran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 23 02:03:19 2003