On Feb 23, 2005, at 3:07 AM, Ulrich Eckhardt wrote:
> Scott Palmer wrote:
>> They
>> hand a file over to the engineering team to incorporate into a build.
>> On their own computers they have their own organization of the files
>> and talk in terms of when they last updated the file, not when the
>> engineering team decided to commit it to subversion.
>
> There is a solution to this, and this is how I do it here:
> - teach them (non-programmers) versioning basics (e.g. the advantage
> of being
> able to backtrack changes)
Perhaps this group is in a completely different division of a large
company, they already have there own policy for maintaining various
revisions of their work. Their work could be large chunks of media
content, for example videos used by online help, or cut scenes in a
video game. Things that subversion doesn't deal with as well as other
tools. The main reason for putting the file in the repository is
simply to be able to reproduce major builds... it isn't used as a daily
version resource for these large media files.
They may not even be our own employees. It could be that the only way
to get the file from them is via FTP, in which case we would have to be
extra careful about preserving file dates, but the point is the same.
If hire a studio to produce some content, I can't expect them to use my
version control system, nor would I want them to.
> - give them a toy repository to play with
> - beat them to use versioning and then only take files that are in
> their
> repository, not files edited by $foo and sent by mail or somesuch.
>
> I believe it was worth it, YMMV.
But it is not always practical. E.g. the .pdf files in my example are
not the 'source' files anyway. The people that put together a build
decide what files will be checked in for the build, not necessarily the
original content creators.
[off-topic]
I hear people screaming don't put build products in version control,
only source files. Not practical if the build product (e.g. pdf file)
can not be made from an automated tool. For example if the author must
manually load the source file and select "Export to PDF" in some
publishing package. Assume this can't be scripted for some reason - it
could be as simple as we can't afford a license to put the tool that
generates the file on our build machine, or perhaps the file is very
expensive in terms of time to build. Another good example is a
programmable logic part for our hardware - generating the file is slow,
the tools are too expensive to have sitting on the build machine, and
the build process is not deterministic. Routing algorithms use random
seeds so building our 'firmware' files for programmable logic might not
ever produce exactly the same pattern of usage within the programmable
parts. Due to clock skew, noise and other factors in the hardware that
might depend on how the logic was laid out in the programmable part, it
is important to keep the build output that works in addition to the
source file that created it..
[/off-topic]
>> When I have to
>> answer something along the lines of, "Did you get the changes I made
>> last Thursday?" I can't go by the commit time that shows the
>> following
>> Monday because that isn't a strong enough indicator that I have
>> Thursday's changes. Maybe I got an update on Wednesday and that's
>> what
>> I committed. If the timestamp (and size, etc.) matched exactly with
>> the file that the creator has, I'm pretty confident that we are
>> talking
>> about the same thing.
>
> I think you see how these problems dissolve to nothing with above
> approach.
In your utopia, sure. I work in the real world. :)
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 23 17:17:57 2005