> The tricky bit will be that I'll get a copy_path on update - and I'll have
> yet to find out what to do about them ... the source might not be
> available, or modified ...
As I wrote - detecting duplicate files is easy. That'll be ready soon.

How do we store that in the repository?
The following ideas come to my mind:

- For each (to be) committed file, create a file named
  REPOSROOT/MD5/x/x/x/x/xxxxxx... (where the x stand for
  the MD5-digits) (could be SHA1, too, of course), and
  do a copy from there into the "correct" location.
  Adv: repos-wide sharing of identical[1] files.
  Disadv: possible collisions
    have to configure MD5 root
    history of files very complicated[2]

- subversion issue 2286.
  http://subversion.tigris.org/issues/show_bug.cgi?id=2286
  Here the repository has the work to consolidate identical files.
  Adv: client doesn't have to change.
    Repos has the necessary informations, as it has to reconstruct
      the fulltext either way, and can easily check for identical data.
  Disadv: Repos has to change[3]

- Use a special property "fsvs:hardlink" => "/repospath/to/file:revision"
  On update fetch the mentioned file.
  Adv: can be done entirely in fsvs
  Disadv: incompatible with everything else
    History mangled - eg. File is identical, gets a change (results in
      local copy with delta), gets identical to some other.
      Then a "diff" is meaningless.


To be honest, I'd prefer the solution with issue 2286 ...
It feels the simplest and cleanest to me.


Any other ideas?


Regards,

Phil



Ad 1: as far as MD5 or SHA1 say they are identical.
Maybe we should take SHA-256, which seems to be better.
(There's a way to generate files with identical MD5).

Ad 2: Would we copy the MD5/.../file to a new name, change it there, and
copy it to the existing location? Then the previous and current data don't
share history, as they're not directly connected.
Or otherwise, if we'd change the "local" location, and copy to MD5/...,
then every identical file copied from there as a bad history ...

Ad 3: There's a thread "Stage 1 of true rename support"      
http://marc.theaimsgroup.com/?t=111661193300004&r=1&w=2 starting
2005-05-20, where I did mentioned issue 2286, and where it seemed to fit
(at least IMO). I did get no answer to that, though.
I don't know the current status of that.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to