Dave Proctor wrote:
>>I don't have experience with this situation, but it strikes me that you
>>don't really want to use subversion most of the time, you just want it
>>for a few milestones. In most cases you just need a backup or central
>>source of a current version of the file.
>
>
> Thats how we currently do it. However, we're looking at switching to
> subversion for the source code to allow things like remote working to be
> possible - and it would be very good if subversion could deal with the whole
> dataset - rather than splitting it into different areas + utilities to get
> the latest versions of things.
>
>
>>Why not just use it that way? Use rsync or other tools to stay in sync
>>with a master copy on the server for most updates. Occasionally, when
>>you want to archive a version, update the copy in your repository.
>
>
> The problem there surely is that if a developer is working on source code,
> and does an svn commit command, with the binary data now being different to
> the repository version, then subversion will want to update the binary at
> the same time as the source code. Unless we specifically have it in a
> different directory. Already thats starting to get unintuitive and error
> prone :-(
>
>
>>You do risk losing changes if someone syncs to a bad version in between
>>commits to the repository, but presumably standard backup solutions can
>>deal with that.
>
>
> Not in a situation where there are remote workers. Backups take time to
> recover, and the chances are if the data's changing frequently this
> situation will occur too many times (unless the developer is careful, each
> time they do a commit! ;-))
>
> I think I know what you're suggesting is pretty much what we'll end up
> doing.... just its not particularly ideal. I think if we do choose this
> path, we'll have to just store the binary data on an ftp server and sync
> with that keeping no revision information apart from manually created ones.
>
> Many thanks for your feedback though!
No idea if this is practical, but how about something along these lines:
subversion allows you to mix repositories in a checkout (see "Externals
Definitions" in the book). So why not keep the big binary file in one
repository, the source in another, and periodically wipe out the binary
repository and start over? Presumably you'd commit a current version
somewhere else whenever you did that. You'd lose all the commit
comments (unless you print a log, and commit that too...).
That is:
On a daily basis your remote workers would work with the main source
code and the temporary binary. All changes would be recorded and
reversible.
Whenever you want to set a milestone, you take the binary repository
offline, commit a copy of the head and the log to some other place,
recreate the binary repository and check the binary file into it.
Hopefully someone with more experience in this than me will comment...
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 19 13:11:03 2005