From users-return-14475-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Wed Apr 11 04:49:53 2012 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 88ABE9D6B for ; Wed, 11 Apr 2012 04:49:53 +0000 (UTC) Received: (qmail 52996 invoked by uid 500); 11 Apr 2012 04:49:52 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 52882 invoked by uid 500); 11 Apr 2012 04:49:48 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Delivered-To: moderator for users@subversion.apache.org Received: (qmail 7513 invoked by uid 99); 11 Apr 2012 00:42:07 -0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Message-ID: <4F84D292.9010106@ivimey.org> Date: Wed, 11 Apr 2012 01:38:42 +0100 From: Ruth Ivimey-Cook Organization: Ivimey.Org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: users@subversion.apache.org Subject: Can (Tortoise) Svn auto uncompress-recompress files to merge/update files? Content-Type: multipart/alternative; boundary="------------010004070606030206060509" Sender: Ruth.Ivimey-Cook@ivimey.org X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------010004070606030206060509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, I'm using TortoiseSVN on Windows 7 talking to a mod_dav server in Apache hosted in Fedora 13. While TSVN is working for me, it might be possible to use another tool if that would help. The svn repo I maintain contains a lot of files for a simulator. The files define the simulator environment and are in fact well-formed XML. However the simulator stores them on disk as compressed files (*.bin), and the so the repo does too. This is all fine, except I lose the ability to track and merge changes. Is there a way (hook?), when TSVN sees a file is different, for it to call an uncompress utility on the files from disk and repo, do the merge/whatever, and then recompress again once finished? I have the compressor (not ZIP - it's special). I emphasise: the use of compressed files is not my choice, it's the simulator's, and I can't alter that. There is never more than one XML file in a compressed file (think gzip not unzip) So, just to be clear, I imagine the current svn_client side_update process to be something like: Code: for each working file do if working version number lower than repo version number {file out of date} if date or size properties differ from base version And checksum differs from base version And file is mergeable {working version modified } fetch latest version {now have 3: base, latest, working } diff3 base version, latest version, working version { now have patch to working } if diff patches don't conflict patch working version else mark for manual merge end if end if end if end for ... probably left stuff out but, assuming it's not too bad, I'm saying : can this be modified to: Code: for each working file do if working version number lower than repo version number {file out of date} if date or size properties differ from base version And checksum differs from base version And file is mergeable {working version modified } fetch latest version {now have 3: base, latest, working } * uncompress just-fetched latest version {read only, temporary } uncompress working version {to be patched, temporary } uncompress base version {read only, temporary } * diff3 base version, latest version, working version { now have patch to working } if diff patches don't conflict patch working version * compress working version {new working version } * else mark for manual merge end if * delete temporary files * end if end if end for Of course, similar changes would be needed in some other code paths, notably view differences. Thanks Ruth -- Software Manager& Engineer Tel: 01223 414180 Blog: http://www.ivimey.org/blog LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/ --------------010004070606030206060509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks,

I'm using TortoiseSVN on Windows 7 talking to a mod_dav server in Apache hosted in Fedora 13. While TSVN is working for me, it might be possible to use another tool if that would help.

The svn repo I maintain contains a lot of files for a simulator. The files define the simulator environment and are in fact well-formed XML. However the simulator stores them on disk as compressed files (*.bin), and the so the repo does too. This is all fine, except I lose the ability to track and merge changes.

Is there a way (hook?), when TSVN sees a file is different, for it to call an uncompress utility on the files from disk and repo, do the merge/whatever, and then recompress again once finished?

I have the compressor (not ZIP - it's special). I emphasise: the use of compressed files is not my choice, it's the simulator's, and I can't alter that. There is never more than one XML file in a compressed file (think gzip not unzip)

So, just to be clear, I imagine the current svn client side update process to be something like:

Code:
for each working file do
  if working version number lower than repo version number {file out of date}
    if date or size properties differ from base version And
           checksum differs from base version And file is mergeable {working version modified }
      fetch latest version {now have 3: base, latest, working }
      diff3 base version, latest version, working version { now have patch to working }
      if diff patches don't conflict
        patch working version
      else
        mark for manual merge
      end if
    end if
  end if
end for
... probably left stuff out but, assuming it's not too bad, I'm saying : can this be modified to:

Code:
for each working file do
  if working version number lower than repo version number {file out of date}
    if date or size properties differ from base version And
           checksum differs from base version And file is mergeable {working version modified }
      fetch latest version {now have 3: base, latest, working }
      uncompress just-fetched latest version {read only, temporary }
      uncompress working version {to be patched, temporary }
      uncompress base version {read only, temporary }
      diff3 base version, latest version, working version { now have patch to working }
      if diff patches don't conflict
        patch working version
        compress working version {new working version }
      else
        mark for manual merge
      end if
      delete temporary files
    end if
  end if
end for
Of course, similar changes would be needed in some other code paths, notably view differences.

Thanks
Ruth 
-- 
Software Manager & Engineer
Tel: 01223 414180
Blog: http://www.ivimey.org/blog
LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
--------------010004070606030206060509--