> We _do_ use Subversion for normal, day-to-day source control on the
> entire source tree and large parts of the data. Other parts of the
> data, however, are not under version control. We tag the source
> repository at each build. This is not what I want - I want to use a
> separate repository to store economically (thanks to the diffy
> storage) the sequence of final builds, with the data preprocessed etc.
Yes - tagging the source repository isn't always enough, e.g. if tools in
the build chain incorporate the current time/date into object files, which
can change file sizes, checksums, etc...
> And I have read the section on vendor branches, and I think I
> understand what a vendor branch is - it's not what I want.
My understanding of a "vendor branch" is that you use one when you receive
periodic "drops" of code from a vendor, without any revision control
information, but wish to store them in your own revision control system,
taking advantage of diffy storage, easy history tracking etc). In this case
the "svn_load_dirs.pl" script imports a new "drop" into a repository,
performing the necessary "svn add"/"svn rm" commands etc.
It sounds like that your situation is quite similar - where each "drop" is
in fact the result of a build, and the "svn_load_dirs.pl" will perform the
adds/deletes that you would otherwise have to do by hand.
If this doesn't apply to your situation, then I'm not understanding what the
difference is - if that's the case, please explain my misconceptions :)
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 4 16:42:15 2004