Merul said:
> Thanks to all the various answers given so far.
I thought it was an interesting question, and I enjoyed reading the
responses too. It's all useful information even to those of us that have
been using SVN for some time.
> I had tried to find
> the answer earlier elsewhere and had posted the question as I hadn't
> found the answer at the time.
Sometimes the answer *is* there already, but you miss it perhaps because
you don't quite select the right search terms. Sometimes someone else
will just supply you with the URL of a pre-existing solution to your
problem.
> The solution for me - which has taken a bit more than the 30 seconds
> suggested - was to created a set of folders constructed as needed
> (some representing organisational units, others working copies) and
> then checking out just revision 1 of each repository to the
> respective
> folder. I can then ZIP the folder structure and distribute to
> my users.
There's one idea I hadn't thought of: an older revision.
For those that this idea would suit, but that don't want to distribute
the root, it may be possible to distribute a particular directory within
a repository in a similar way *if* an empty containing folder was
created is some early revision. That is what often (but not always)
happens with trunk work: create an empty project directory and commit
(as, say revision 1000), then add the initial versions of the files, and
perhaps subdirectories and commit (say revision 1005). Then revision
1000 of the directory may be checked out, zipped and distributed, to be
unzipped and updated by the recipients.
Mark mentioned that:
> Also, why an empty checkout? I know a lot of people that have a group
> of users on a LAN, when the repository is elsewhere, will make a
> complete checkout available in a tarball/zip and posted to a file
> server on the LAN. Then new users can get the tarball from the LAN
> server, extract it and run svn update to just have to get the deltas
> from HEAD in the repository.
That reminds me of another point:
An unmodified working copy contains two copies of every file (one of
them being the BASE version, to allow off-line reverts and some other
off-line operations). Therefore a compressed package of this may be
about twice as big as it needs to be (in the case of a *.zip; for a *.7z
or *.tar.gz, that might be less relevant). So, before zipping such a
thing, you could delete (using the OS or shell, not the svn client) all
working copies of unmodified files. These will appear as "missing" ("!")
in the working copy. When unzipped, a recursive revert will perform an
off-line restore of all the missing files. It will also undo any
modifications, but those can be recovered by unzipping again. That will
probably also restore property changes. I have not tested this.
If the repository is available, which will be required even for an
update to the BASE revision, then the update should be quick because I
imagine that the locally stored BASE versions of the files will still be
used for deltas to reduce the traffic between the repository and the
working copy. Again, I've not tested this.
[My earlier comments that this might cause problems for users with
clients incompatible with this (version of) the working copy still
apply. I suppose that this method is okay when the group in question is
a close group of collaborators, with know versions of the clients,
rather than to a wider, uncontrolled audience.]
Thanks,
Rob.
________________________________________________________________
This message has been independently scanned for the Softel Group and cleared of containing viruses and other malicious data.
Powering Television Beyond the Video (TM)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1237741
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-27 10:32:40 CET