On May 28, 2007, at 03:35, Holger Schulz wrote:
> after installing Subversion via fink on MacOS X 10.4.9 and
> running some test, I have some questions which some of you
> might be able to answer.
>
> 1. Okay, the data in my repositories will mainly be LaTeX files,
> since I need these for my work. Typesetting will produce PDF file,
> which shouldn't be merged but overwritten. Does subversion know that
> overwriting is necessary in these cases ordoes I have to tell it
> somehow? Same question for MS-Word documents and similar which I have
> to use sometimes in collaboration with some colleagues.
Subversion does handle binary files just fine, but it will not
blindly overwrite data. If, for example, two people independently
modify a PDF or Word document, then there will be a conflict, which a
developer will have to resolve by examining both versions of the file
to determine what to do. With text files, you would get a line-by-
line diff, but it can't show you that with binary files since it
doesn't know how to interpret binary formats.
Note that many will recommend not storing generated files in the
repo. In your case, if the PDFs are generated from the LaTeX files,
then store the LaTeX files in the repo along with a script that
generates the PDFs, but not the PDFs themselves.
Others will give you different advice, hinging on the fact that the
software needed to generate the PDFs may be hard to install, or that
its version may change and its output might thus change, and that one
would want a record of the way the PDFs looked with the old software.
> 2. Currently I have a G4 desktop which holds the repositories. I also
> have a PowerBook which I you for work at home and from outside. At
> home I connect the desktop from the book via its Bonjour name
> <something>.local, to connect it within my local net. From outside I
> have to use a global name (in this case via dyndns). So the problem
> appears that the same repository might apear under two different
> names. How can I tell the working copy that its repository has
> "moved"?
In the working copy:
svn switch --relocate $OLDPREFIX $NEWPREFIX
where $OLDPREFIX and $NEWPREFIX are the parts of the URL that
changes. For example, if you're relocating from svn://foo.local/repo
to http://foo.dyndns.org/repo then you could issue
svn switch --relocate svn://foo.local http://foo.dyndns.org
However, I highly recommend that you set up a single hostname under
which you can access the repository regardless of where your laptop
is located. You will find this much easier, and if you want to use
svn:externals, this is the only way it will work everywhere. For
example, if you have a DNS server on your local network at home, you
could set up foo.dyndns.org to be a CNAME to foo.local there, and for
the rest of the world it will still be your machine's public IP.
> 3. What is a good way of backing up repositories? My current test
> repository is located in my Documents folder, so it will be included,
> when I burn this folder on CD. Will this copy be work after playing
> in back from the CD in case? Are there better ideas?
That should be fairly safe, if you're using FSFS repositories (which
are the default since Subversion 1.2), and especially if nobody is
modifying the repository when you take the backup. You would need to
make sure that the machine on which you restore the repository also
uses a PowerPC processor (an issue if you try to restore to an Intel
Mac, for example, or most PCs) and has at least as recent a version
of Subversion as the server does now.
If using BDB repositories (which I don't particularly recommend on
Mac OS X), then you must also ensure that the system on which you
restore the repository has the same version of BerkeleyDB as the G4
does now. Also, BDB repositories get written to even when people are
just reading from the repository, so you should ensure that nobody is
reading from or writing to the repo while it's being backed up in
this manner.
It is more portable and safer to back up the output of "svnadmin
dump" which works independently of the processor architecture and the
version of BerkeleyDB, and can be done safely regardless of whether
anyone is reading or writing at the time. Also, you can do
incremental dumps with this utility, which could be useful if you're
doing permanent backups to CD.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 28 11:17:25 2007