[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-issues
Subject:    [Issue 677] Changed - support versioning of symlinks
From:       issues () subversion ! tigris ! org
Date:       2002-10-29 16:13:47
[Download RAW message or body]

http://subversion.tigris.org/issues/show_bug.cgi?id=677

*** Old
--- New
***************
*** 52,54 ****
--- 52,117 ----
  
  ------- Additional Comments From kfogel@tigris.org  2002-08-01 07:26 PDT -------
  Front page now says Post-1.0.
+ 
+ ------- Additional Comments From hadaka@tigris.org  2002-10-29 08:13 PST -------
+ Attaching my mail about the issue here so it doesn't get lost
+ 
+ ***
+ 
+ I've gotten a few Profound Revelations, from which the
+ most important one is this:
+ 
+   Special file storage is just another case of working copy file
+   translation.
+ 
+ First of all it's completely client side. It doesn't affect the
+ text-base at all. To find the differences in a file, one has to first
+ de-translate the file and then compare that to the working copy
+ base. Everything fits. So, newline translation, keyword substitution
+ and special file handling should all be done mostly at the same places
+ - everything else is just edge-cases.
+ 
+ So - good - how to do it then? Again, I have two options in how to
+ proceed. The first is the straightforward one - and the second
+ is... well you'll see. So, on to the first choice.
+ 
+ * Straightforward extension for special files
+ 
+ Add a new argument to svn_wc_copy_and_translate, which controls the
+ translation of the text form to the actual special file and back. Then
+ specify a single property, which tells if a file is a special file or
+ not.
+ 
+ After that, it's a simple case of fixing up all callers of
+ svn_wc_copy_and_translate - and fixing up snv_wc_translated_file,
+ svn_wc_text_modified_p and such special functions.
+ 
+ And then finally just testing it around in several situations and fix
+ up the edge-cases that pop up.
+ 
+ This sounds straightforward, not too cumbersome - but not too elegant
+ either. In the worst places right now, there's checks of
+ svn:executable, svn:keywords and svn:line-style - after this, there'd
+ be one more again.
+ 
+ * Visions of grandeur - pluggable translation
+ 
+ Instead of adding a yet another parameter to the translation functions
+ - abstract them more. Decide the forms a file can appear in - I've
+ been initially thinking about: untranslated (eg. text-base form),
+ fully translated (normal working copy form), merge form (eg. used in
+ conflicted files). Then start separating the hard-coded keyword and
+ newline parameters and instead use a generic translation
+ interface. Once there's just simple functions for translating and
+ de-translating files, separate newline translation and keyword
+ substitution into separate files.
+ 
+ After that, make the translations pluggable - come up with a dynamic
+ loading scheme for pluggable translations, like the ra-interface. And
+ then, finally, implement the special file storage.
+ 
+ Obviously, special properties, such as svn:executable, should be tied
+ in at some point as well, even though they do not consist of
+ translation as such.
+ 
+ ***

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@subversion.tigris.org
For additional commands, e-mail: issues-help@subversion.tigris.org


[prev in list] [next in list] [prev in thread] [next in thread]