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

RE: hooks to facilitate source conversion from binary form to text and back

From: Todd C. Gleason <tgleason_at_impac.com>
Date: Wed, 30 Sep 2009 14:54:49 -0700

> -----Original Message-----
> From: Simon Large [mailto:simon.tortoisesvn_at_googlemail.com]
> Sent: Wednesday, September 30, 2009 3:48 PM
> To: users_at_tortoisesvn.tigris.org
> Subject: Re: hooks to facilitate source conversion from binary form to
> text and back
>
> 2009/9/30 Stefan Küng <tortoisesvn_at_gmail.com>:
> > On 30.09.2009 17:06, Eduard Alexandru wrote:
> >> I'm a visual foxpro developer and the bulk of visual foxpro source
> >> files are in binary format (foxpro compatible tables).
> >>
> >> In order to use the svn's compare and merge facilities compunity
> >> members have created tools to perform the convertion of source files
> >> from binary form to text (xml files) and back to binary form. The
> >> files places and source control are the xml versions.
> >
> > Are those tools opensource? If yes, where can I find them?
> >
> >> The process is simple, however tedious and i hope that in some future
> >> version the TortoiseSVN team will add pre/post hooks to "Check for
> >> modifications" and "Checkout" operations so users like me could hook
> >> the conversion tools directly into TSVN.
> >
> > Actually, it's quite easy to do this now without the need to change
> > something in TSVN:
> > create a diff script for those foxpro files, and configure TSVN to use
> > that diff script (settings dialog->external programs->diff viewer-
> >advanced)
> >
> > in your diff script, you should call the conversion tool, then pass the
> > converted files to TortoiseMerge (or any other text diff tool you like).
> >
> > And if you have that script ready, we'd appreciate it if you could make
> > it opensource and send it to us so we can include that script in TSVN.
>
> That would be true if the files were stored as binary in the repo. You
> would need to convert both mine and theirs to XML in the diff script.
>
> But IIUC the files are stored as XML in the repo. So after checkout of
> the xml files he would like a hook script to convert them to binary
> (unversioned, ignored) to do the real work on in foxpro. In order for
> CfM to work you have to convert the modified binary back to XML so
> that you have something to diff against. And when doing an update you
> need to convert the binary back to XML before the update, so that
> subversion can merge incoming changes, and convert to binary after the
> update so that you can continue working in foxpro on the updated
> files.
>
> So client side hooks is what is required here.

Another option: it would be pretty easy to write a utility or service to just watch those files, and when one is saved and closed, automatically generate the other. You (Robin not Simon) might have to be careful not to do it while there is an outstanding conflict on the XML file, but other than that, you could consider doing this instead of expecting TortoiseSVN to solve the problem.

If TortoiseSVN did solve the problem, wouldn't it have to cover any time it writes the XML file, which includes merge, revert, update, switch, and apply patch? And what about manual editing/merging of the XML file? Any time any of that happens, you might open it in FoxPro right after. And when FoxPro is done you might then want to open the XML file in a text editor.

Since there are a few use cases that don't even affect TortoiseSVN--and since you could easily use another Svn client and bypass TortoiseSVN especially for doing updates, I don't see TortoiseSVN effectively solving your problem here.

--Todd

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2402305

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-10-01 00:00:45 CEST

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

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