On 7/31/06, Hans-Emil Skogh <Hans-Emil.Skogh@tritech.se> wrote:
> Just out of curiosity: ~How many files, how many MB?
About 16GB, 190,000 files, and 90,000 folders, including WC .svn
directories, and some unversioned built data sharing the same folders
as versioned data. The vast majority (~85%) of these files are
versioned. The repository is about 20GB, with over 12000 revisions.
Both art and code are versioned here.
> Subversion always (what I have seen) puts safety first.
> The method to find modified files used now guarantees that a commit operation will get all changed files, as SVN will verify every individual file.
Who wants to commit every single file? That's why there are checkboxes
on the path list on every TortoiseSVN GUI Commit, I presume -- to give
the user the power to dictate what specific paths get committed at any
time. I'm just talking about giving the user more control options.
What we would find most useful, in all these cases, is an option
to say "we don't want to do the slow NTFS directory walk -- we already
know the specific paths we want to work with." We might not even
choose this option every time -- just most of the time. :) With these
"most of the time" options, I find it's much more convenient to make
it an ini file config option, rather than to force the user to
manually select it each time. They can choose to turn it off, the few
times they want to go the old, slow way. I assure you that would be a
very rare choice around here.
> To me this seems like quite specialized requirements.
> Personally, I do not think they should be a core part of TSVN.
Personally, I do. I'm not saying it needs to be the only option, and
not even the default option. I'm just saying the more options, the
better, and this is one we could use right now.
> However: There's a long time standing issue in our issue-tracker regarding hooks for TSVN. I guess your ideas (as a separate program) could be integrated with TSVN quite nicely if such a feature was implemented:
> http://www.tortoisesvn.net/issues/?do=details&id=137
>
> Maybe that would be a good place to start?
Is this feature just for commits and updates, or for all commands
involving the repository? Yes that would be nice.
> Everything that clutters the GUI even more is usually frowned upon. But share your specific ideas with the mailing list and check out the response!
Uh... I thought that's what I'm doing now. ;) Oh, you probably mean
the users list. Yeah, I just wanted to get a better idea of internal
development policies first.
If the changelist props thing becomes part of the mainline
Subversion, a similar GUI will become necessary anyway. This would be
similar to the list of historical Log messages TortoiseSVN has now.
Maybe a drop-down list of changelists could be chosen, rather than
checking and unchecking paths one-by-one.
> > My users don't care if the files they are Committing are not up-to-date, as long as there are no merge conflicts.
> Maybe they should care?
When you're dealing with users, especially knowledgeable users like my
programmer staff, I find the best assumption is: they know what they
want, and if it is in your power, you should give them the option to
get exactly what they want. I see no good reason not to allow them to
Commit without a manual Update cycle.
> > 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.
>
> Why? I cannot see the point of doing this. Maybe you should have a look at svn:needs-lock?
I am familiar with svn:needs-lock. We have no use for it when files
can be merged, and merged automatically at that (without user
intervention). I just want to extend this "power to merge" with a
related "power to update/commit", without user intervention as well.
The Lock in this case only serves to prevent others from sneaking in
smaller Commits on a path subset while a larger Update/Commit cycle is
in progress. I will probably give users an option to Release the Lock
if any Conflicts come up. Locks would be released after successful
Commit by default.
I don't see the need for user intervention if an Update/Merge is
all that is required for a successful Commit. It's part of my strategy
for handling errors gracefully and automatically whenever possible,
rather than unnecessarily annoying the user.
> Probably a NO right away. But I'm just guessing here. :-)
Okay. Well, how do I track the status of the pre/post-command hook
feature mentioned above? I guess I'll continue going it alone until
that's done. I'm sure others would benefit from the workflow options I
mentioned, but I suppose they will have to do without, if that is the
policy. ;P
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Aug 1 02:34:52 2006