On 8/1/06, Hans-Emil Skogh <Hans-Emil.Skogh@tritech.se> wrote:
> > About 16GB, 190,000 files, and 90,000 folders,
> > including WC .svn directories
>
> That's a pretty massive WC indeed! :-)
I think this will start to become more common as more true multimedia
projects start to see the benefits of Subversion. Personally, I
haven't seen any repository model that can handle binary files nearly
as well, especially with the FSFS storage model, and diff network
transfer. I am already an evangelist of such use, but I'm finding it
tougher to counter spurious claims like "it's slower than Perforce" at
my work place, due to the forced directory-walks. I have used Perforce
in the past, and while the clients show a lot of polish, I don't like
their repository model at all, and their check-out-status-centric
client model causes a lot of synch and scale issues. ionForge
Evolution SCM may be a new, stronger competitor in this area, but I
haven't evaluated that thoroughly yet.
I guess our type of production is a lot higher-speed iteration
than most, since we have 30 users on the gigabit LAN with an average
of 2 commits per day, 4 per day during crunch time, per user. This is
a more common environment for multimedia projects than OSS projects,
so I guess it makes sense that this is a new idea to some. It may be
"specialized" now, but I definitely see similar use cases becoming
more common. New XML multimedia formats like SVG and Collada lend
themselves much better to concurrent development environments than old
binary formats. Single-user local Repositories are another use case
talked about frequently on the Subversion mail lists, especially with
the new real-time OS configuration versioning projects becoming
available now. I think analysing Server data or utilizing local
write-access path cache, to limit directory-walk time, may be a
benefit to those use cases as well.
> > Who wants to commit every single file?
> Most knowledgeable programmers for example.
Touche. ;P Actually, our project is fairly well segmented, so we often
limit commits to one segment when we are working on multiple segments
at the same time. Segments get completed at different rates, so we
don't want to be forced to commit unfinished segments with complete
ones. We only tend to do all-changes-at-once type commits when some
central library or tool has changed that affects all segments. This
project segmentation is part of why we are looking into implementing
changelist handling features.
> > 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...
As I said, I think the use case I describe is gradually becoming much
more common. I also don't see any harm in exposing *more* features to
the user, when feasible. I think it's always better to let the user
customize their environment, than to force policy via synthetic
implementation limits. I look at this kind of programming just like I
look at the US Constitution: it says "the pursuit of happiness",
rather than "a right to happiness", or "we know what will make you
happy better than you do, so just obey." :) Our current leaders should
take a better look at that sentence.
> Then, of course, there's the small matter of implementation. The best
> way to help there is to provide some (working) source code!
My current code is way too specialized to our environment for general
release. That's why I was considering changing to TortoiseSVN patch
development instead. I am in the early process of getting my VS.NET
TortoiseSVN Solution environment set up.
> 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?
The general feel I get there is that, because svn is all command-line,
people are actually just wrapping it with their own batch/shell
commands, which is what I've done so far. Some are even going as far
as implementing a complete wrapper to svn.exe, which runs custom
versions of the same commands. I think the complications of GUI
environments lend themselves better to hook-scripts than similar
wrappers.
> I was referring to changes in the GUI. A mock-up screenshot (.png bitte)
> or similar is a good starting point for discussion.
Good idea. I'll put that on the users list when I have something to show...
> > 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.
No -- they really do tend to earn my regard. Even if they didn't, they
manage to work around any interface limits they are given, on their
own, and just complain about the extra work steps that the interface
limit creates. It's much easier to eliminate the work steps by giving
them the desired interface.
> 1. Make changes
> 2. Test
> 3. If test fails, goto 1
> 4. Update
> 5. If new stuff in update, goto 2
> 6. Commit everything
We often find step 5 unnecessary if there are no conflicts, because if
the committed code changes work independently, it's usually a safe
assumption that they will work together as well. Our build/test cycle
takes care of the few cases where this assumption doesn't hold true. I
understand that this is not usually a good assumption in most
environments, but it works for us, and I see no need to work with
others' assumptions.
> 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?
Yes. We are using manual locks on some committed build binaries as
ad-hoc semaphores to get around these "concurrent commit" issues, but
such human-maintained semaphores are very limited in value. I think
temporary locks on all intended-commit paths would serve this purpose
much better.
> I might be misunderstanding you, but since you need to test the result
> of the merge, you DO need user intervention. (See workflow above.)
The committer is not necessarily the right person to do all testing.
QA and automated build/test servers handle that work post-commit just
fine for us. I would agree if we considered trunk to be a stable
branch, but we consider it our iterative-collaboration branch. Maybe
this isn't a "best practice", but it works for us.
> > Well, how do I track the status of the pre/post-command hook
> > feature mentioned above?
> On the issue tracker.
Ah -- didn't see the "Track this issue" option at first. Now I'm
registered, and have it tracked.
Thanks!
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Aug 2 01:18:39 2006