I want to preface this by saying: I understand just keeping up with
Subversion features is a big task, and I appreciate all the work that
has been done. TortoiseSVN is a great intuitive Windows client
interface for Subversion, and I'm sure my artist staff thanks you, as
do I. The programmer staff has mixed feelings, as they tend to stick
to command line scripts, and clients like SmartSVN, but many of them
love Tortoise as well.
One theme in development here seems to be sticking strictly to
Subversion for all task definitions. For instance, when I searched for
e-mails and bugs about the local-file-lock update and cleanup issues,
and the issue where local-unversioned file has the same name as a new
repository file, which needlessly prevents WC status updates, people
were most often referred to the Subversion mailing lists for these
issues. I have taken to writing small scripts with relatively simple
fixes around these problems (involving rename tricks), and
distributing them as SendTo folder shortcuts to gain right-click
access, while we wait for real fixes to get to stable releases.
One of the more complicated Subversion wrappers I have been
working on involves getting a folder's WC version number, getting the
current Repo version number, getting a "log -v" listing all the files
changed between these two versions, and doing an update on only those
files. It uses the same rename tricks mentioned above, to avoid
requiring cleanups. I call it "FastUpdate", and it is getting used a
lot around here, even though it's in a buggy alpha/hack stage. We have
a *lot* of files and directories in our repositories, and NTFS
directory-walks are painfully slow, so this speeds update times a
great deal, especially on the LAN. The only problem is that they have
to do occasional normal/slow svn updates to keep the WC folder version
numbers up. Many people have full updates scheduled tasks at night, or
during lunch break, to keep the slow updates from cutting into
development time.
I realized that I should start some of my more complicated svn
wrapper work as extensions to TortoiseSVN, rather than going it alone,
as I have been. I will want to try to contribute this work as patches,
but I was wondering, what is your policy on extending definitions of
Subversion tasks? It seems logical to me that TortoiseSVN is
Windows-only, so it should be capable of some optimizations with that
assumed environment. Subversion may not be capable of doing the same
optimizations, because of cross-platform issues. But this kind of
optimization doesn't seem to have been done, so far. Am I missing a
counter-example?
Here is one example.. I was thinking of writing a small
Shell-Extension script, that would detect any file Modify operation
(like an Anti-Virus does), and figure out if that file is versioned.
If it is, I would append it to a simple text file, a list of paths,
which would be maintained per-WC. This text list could be used with
"--targets" capable svn commands. I would also use it on any Commit,
rather than searching for all file changes via the slow NTFS directory
walk. Any file in the list that is successfully Committed would be
deleted from the list. Additionally, I would support allowing users to
create, name, and maintain their own lists, which could be used in the
same ways. This would give them a crude approximation to
"Change-Lists" feature support. There have been rumblings of a similar
change-list props feature in Subversion 1.4, but the
text-list/--targets system might be easier for certain users, and
require less filesystem searches. This would be something I try to
integrate into TortoiseSVN, to alter the Commit GUI with Change-List
selection and naming options. Would this be allowed?
My users don't care if the files they are Committing are not
up-to-date, as long as there are no merge conflicts. They are also
annoyed by the occasional collision, where they are doing a big
Commit, just as someone else submits a smaller Commit with a subset of
the same files. I would like to make a different "Commit" for these
users, that does all these tasks, in this order, for all files: Lock,
Update, check for conflicts and resolve them, and last Commit all. I
would want to make this seem as one operation, still called "Commit",
or maybe "Check In". I might offer them a checkbox, and an ini config
option, to make the usual plain Commit instead. What would be the
policy on such a change, to TortoiseSVN command definitions?
Thank you,
Jared Hardy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jul 31 10:10:55 2006