>> 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.
That's a pretty massive WC indeed! :-)
> Who wants to commit every single file?
Most knowledgeable programmers for example.
> 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.
Yes, but it should be used with caution. One big selling point of SVN is
atomic commits. When making changes to many files that have relations,
it is important that these changes are tested and committed as one.
Committing from the top directory in the WC is often considered a best
practise when working with SVN.
(Of course things are different when you are working with self-contained
files (art maybe). Then there's no problem with committing file one
after another and no test-implications with leaving a specific file out
of a bigger commit.)
> 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."
I understand what you want to do. I do not doubt that it would be a very
good feature for you. But it still sounds specialized to me. For the
average user I think it would be confusing and contra-productive.
I do not say that it's a bad idea. Quite the opposite! But it *might*
not be the right place for it as a part of TSVN...
>> 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
> Is this feature just for commits and updates, or for all
> commands involving the repository? Yes that would be nice.
It is not implemented yet... All suggestions are welcome! Commit and
Update seems like clear cut cases where hooks would be suitable. If you
have any suggestions regarding more hooks then I'm sure they will be
added to the issue.
Then, of course, there's the small matter of implementation. The best
way to help there is to provide some (working) source code!
I'm not that up to date with the latest things happening over in the
SVN-camp. Does anyone know if there are any ideas of implementing client
side hooks on that level? Because if there are we might be better of
waiting.
>> 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. ;)
I was referring to changes in the GUI. A mock-up screenshot (.png bitte)
or similar is a good starting point for discussion.
What I'm trying to say is: If you provide a patch for doing things
"behind the scenes" it's more probable to be accepted right away than a
patch that changes the GUI.
> If the changelist props thing becomes part of the
> mainline Subversion, a similar GUI will become
> necessary anyway.
If that happens, I'm sure TSVN will support it. Just like all other
features of the SVN-project.
>>> 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.
You might have your programmer staff in a little to high regard here.
1. Make changes
2. Test
3. If test fails, goto 1
4. Update
5. If new stuff in update, goto 2
6. Commit everything
The above workflow assures the consistent state of the repository by
relying on the atomic commits of SVN.
If you diverge from that routine, you have no way of knowing if a
certain revision in the repository might be broken. Think about it.
>> 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.
Ahh! You want to guarantee serialized commits. Hmm... Maybe not a bad
thought. Q: Have you experienced real world problems from "concurrent"
commits when using the workflow I outlined above?
> I don't see the need for user intervention if
> an Update/Merge is all that is required for a
> successful Commit.
I might be misunderstanding you, but since you need to test the result
of the merge, you DO need user intervention. (See workflow above.)
>> Probably a NO right away. But I'm just guessing here. :-)
> Okay.
> 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
Nah. It's not the policy; it's just one guys opinion. So do not despair.
:-)
> Well, how do I track the status of the pre/post-command hook
> feature mentioned above?
On the issue tracker.
(http://www.tortoisesvn.net/issues/?do=details&id=137) Please note that
the issue was filed approximately a year ago, and nothing has happened
since.
I think there are many questions regarding the feature that has to be
figured out before it's implemented. (Where are the hooks stored, how
are hooks assigned to repositories/WC:s/paths and so on...)
Maybe the time has come to tackle those problems?
Hans-Emil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Aug 1 10:21:24 2006