[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: storing software releases in Subversion - how?

From: Patrick Smears <patrick.smears_at_ensoft.co.uk>
Date: 2004-08-04 16:41:29 CEST

> 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 :)


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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.