In a message dated: 24 Feb 2003 18:45:30 +0100
Alessandro Polverini said:
>So, I'm wondering: would it be possible to implement this behaviour in
>svn, when checking in files that have a certain property set:
>- gunzip the file
>- diff it with the previous (gunzipped) file
>- store differences (diff works well enough with xml files)
>and when updating or checking out, making the opposite.
This could probably be done, however, now you're talking about adding
complexity to svn and requiring it to figure out what types of files
you're dealing with. While this may be a possibility in the future,
(I am not an svn developer, and not trying to speak for them :)
I don't think this is a feature you will likely see very soon.
You could probably write a wrapper function to svn which would easily
handle this for you however. And if you wanted to get creative, you
could use a property tag for your files and have your wrapper check
the tag before attempting the commit.
For example, say you're checking in an OO file, you could set a
property tag, say 'file-type' and set that equal to OO. When
committing changes to this file, you could check the file-type
property and unzip/commit as necessary.
This wouldn't be too difficult to do at all in perl, since you can
use the GetOpt::Long module to swallow the options which need to be
passed into svn ci/co later using a system() call.
The real tricky part is this, each OO file is in fact compressed, but
it's not a single file, it's 5 files and a directory (at least for OO
writer). So, do you version things like the styles and settings xml
files, or just the content.xml file?
It's perfectly understandable to want to version the entire archive,
since the only changes you may make are in the layout or settings.
If all you want to do is version the contents.xml file that should be
quite straightforward. If you want to version everything, then I
suggest that your wrapper script:
- create a subdir for each new OO file
- extract the archive into that directory
- add all the files to svn
- commit with an appropriate log message
- commit the archive with the original message
This hides the ugliness of this hack from the casual user who doesn't
care about the versioning of the archive elements, but allows a
project lead to go in and look at the raw xml changes in the archive
if you ever need it.
I started writing a quick perl script to do some of this, and then
discovered OO archive format, and realized I had no idea which way
you wanted to go. So, I leave the writing of a wrapper up to you,
since you're the only one who really knows what you want and how
complex you want this to be :)
Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Feb 24 20:21:33 2003