On 8/2/06, Hans-Emil Skogh <Hans-Emil.Skogh@tritech.se> wrote:
> Unrelated question out of curiosity: As you are working with "media",
> how are you handling diffs?
If by "media" you mean art/sound binaries like 3D files, images, and
sound files, then yes. Most of these have svn:needs-lock properties
right now. There do exists some limited media diffs -- ionForge has a
bmp diff tool available, for example. We don't use any right now, but
it may be a nice option in the future. Artist tasks tend to have far
less overlap than programmer tasks, in general.
> I have not looked into SVG that much (and Collada was a new format for
> me), but my earlier experiences with concurrent collaborating thru
> XML-formats has been quite disappointing. Often the tools modify the
> XML-source so heavily margining becomes difficult or impossible...
We would probably end up with some kind of visual tool -- visual diff
based on a custom variation of OSS viewers. Collada has an OSS viewer
provided by Sony, for example. I imagine the conflicted diff sections
could be itemized for any two items, without the user needing to know
the XML source details. Three view panes would be presented, all using
the same camera. The pane on the right and left would correspond to
the two different source Collada files, and the middle one would
correspond to the end-result of any diff section choices. Some form of
diff highlighting in the 3D view should also be possible, maybe with a
colored wireframe, or vertex highlights. I imagine something similar,
with a path diff highlight option, should be possible for SVG.
XML media files are large and complex enough that we don't want
anyone manipulating XML source directly, not even the programmers.
It's nice to have the media in programmer-readable form via XML, but
only for desperate debugging purposes.
> More features are not always a good thing. Not when the features lures
> you into thinking it does one thing, but in reality does something else.
> (Not that your suggestions necessarily does that, but I do feel that
> it's a bit of jeopardy to rely on file-system-monitoring. What about
> thumb-drives? Dual boot systems? WC:s on networked drives? And so on...)
Actually, the way I imagine it, the main TSVN feature change is to
handle text file path lists, and possibly be configured (via ini) to
use a "default file" path list rather than doing the slow
directory-walk. The directory-walk option would still be the ini
default, and still be an option for generating a path-list at
run-time, even when it's not the default. The mechanism by which these
alternative path-lists, "changelists", or "target files" (all
interchangeable terms in my view) are generated could be up to the
user as well. I just imagined the Shell-Modify-Tracker would be a good
way to automatically generate a default path list for such use. It
seems svn tools with "--targets" tags are already allowing this form
of customization, and I think TortoiseSVN should follow suit. The
Shell-Modify-Tracker is just a Windows-specific addition to this
"changelist" system that many TortoiseSVN users could directly benefit
from.
> One also has to think about usability when adding features. If dialogs
> get too cluttered, it gets more difficult to use them. I do not mean
> that one should avoid new features, only think hard about where to put
> them and how to design the UI for them.
That makes sense -- I hate GUI clutter too. But I also hate
3-click-minimum processes for frequent tasks, so sometimes that has to
be balanced against the desire for minimal interfaces. I think
changelists UI elements could be kept paralell to log-message-history
lists as they are now in TSVN Commit GUIs. I think the clutter can be
kept to a minimum this way. Anyway, I'll try a to make a quick mockup
in GIMP when I get a chance, and post it to both dev and users. :)
> *(Disclamier: This might not apply if you are the guy sitting in
> helpdesk and tries to help ignorant users with their clients
> tailor-configured beyond all help...)
Hah! :D Yeah, I guess usually I like the customization options to be
there just for my sake. Then I deploy the custom ini, don't tell users
how to edit it themselves, and then everyone tends to keep to the same
config. At least it's consistent for our *internal* helpdesk. :)
> Nice! Keep the list posted with your development progress if you are
> interested in (possible) feedback!
> In the end it's Stefan who has the saying of which patches that goes
> into the TSVN-source, but as long as it does not conflict with his ideas
> of what TSVN should be; all patches (in my experience) are very welcome
I'm having some minor issues since I use VS.NET 03, and so I'm trying
to use VS.NET 05 Express Edition with the TSVN solution, which doesn't
give me Resource Edit or View access. I may just make a mock-Solution
in 03 with pointers to the same resource files, and see if I can go
back and forth the few times I want to make resource tweaks. What
version of VS.NET do you all commonly use?
> Maybe you would simply be better of simply switching to a more
> "module-based" repository setup. I assume that each of your "commit
> paths" consist of a strict sub-tree of your repository.
<snip>
> (Oh, I do not know if I'm making any sense here. Just tell me if it's
> not possible to understand what I'm trying to say...)
I know what you're saying, and most of our directories are fairly
modular. The problem is that we are actually making a complex game,
and our AI system has some cross dependencies between art file
embedded-variable data, and code files, which we try to segragate
otherwise. So the AI system, for example, is impossible to keep
per-directory modules entirely separate. This is one example where
selective commits, or changelists, become useful.
> That's true. That's why you (IMHO should) have an automated test-system
> that automates the tests each developer has to do at point two.
We run builds and tests on a central "Build Server", rather than have
the individual developers run it all. Developers run a minimal subset
of these tests locally before commit. I guess we care more about high
iteration than safety here. The "Build Server" runs off of data from
the trunk, so trunk commits are necessary before the process can be
run. This might be alleviated if we moved to a per-user-branch system,
ran build/test cycles from those branches independently, and
automatically promoted to trunk only after successful test cycles, but
we haven't gotten that fancy with our branching policies, nor our
build tests, quite yet. I would also like to have more fancy
merge-tracking tools, which the Subversion devs are talking about now,
before moving to this kind of development workflow.
> I would try to move as much of that as possible to step 2. Of course
> stress-tests and such may only be possible to do on a nightly basis, for
> example.
Automated stress tests on something as complex as a game are very
difficult to write, and take a very long time to run through. They can
involve "running" a character through an entire level, which I would
say is "literally running", except that it's a game, so the character
is not a physical being. :) It just takes as long to "run" as a
physical being would. Those tests definitely come well after a commit
is done. They are only really guaranteed to happen before promotion to
a release branch.
> How do you handle the occasional breaking of trunk? Do you dissencourage
> regular updates?
We try to fix any critical trunk problems as soon as they're found,
and we don't recommend any mid-day updates, unless a user needs to
work with someone else's changes to get their own part done. Most work
can be done fairly independently, so forced updates are pretty rare.
> Otherwise the risk is to have a large part of your
> development team waiting for one individual to fix the problem that
> prevents everybody else from continue working. (Or if everyone fixes it
> locally you *will* have a conflict later on, not to mention the wasted
> time on many developers doing the same ting.)
The worst case is that they just have to revert to a prior version,
and only update to HEAD when the known fix is in. This usually doesn't
take long at all. We keep tools modular enough that one broken tool
wont break everyone's pipeline.
> And not doing regular
> updates might bring merge-problems when the update is done. (That might
> not be a big issue if all development can be done in small and very
> controlled increments.)
Due to a good division of labor, and frequent (usually small)
iterations on every asset, merge problems are very rare here.
:) 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 21:23:18 2006