Special File Storage - Visions of grandeur

[Nuutti Kotivuori <na...@iki.fi>]

Okay, it's been a while since the last discussion - and I've been
thinking about the matter and browsing around the code.

As a result, 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.

***

So. Thoughts? :-)

-- Naked

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

Re: Special File Storage - Visions of grandeur

[Nuutti Kotivuori <na...@iki.fi>]

Karl Fogel wrote:
> My main thought right now is, can you attach your vision of grandeur
> to the issue? :-)

Just did.

> The proposal looks good; we still need to know the user interface,
> though.  For implementation I prefer your "straightforward"
> approach, as a lot of factoring will get done naturally that way
> anyway.

Yes, further thought has provoked me to go down that line as well -
but that will mean lots of nasty questions about how translations
should happen in working copies to the list :-)

> I don't mean to be discouraging, but there are just too many other
> hot issues right now, so we can't spend much time on special files
> support (at least I can't, and the same is probably true for many
> other developers).  It will be a great feature when we have it, but
> since the latest proposal wonderfully does not require any libsvn_wc
> redesign, that means we don't have to worry about painting ourselves
> into a corner if we wait.
>
> If you have usage scenarios and/or a working patch, there's no
> reason they can't be committed when ready.  I'm just pointing out
> that you're in the driver's seat if you want this to happen before
> 1.0 :-).

Yes, I'm perfectly aware of this. It's just that I consider special
file storage as an important feature of subversion - even for
1.0. Perhaps not quite the kind to hold up 1.0 for, but important
still. So yes, I'm quite fine to be in the driver's seat - that's why
I started thinking about this.

Though, I personally consider ra_pipe a requirement for a 1.0 release
- so I'll prioritize it over all other projects in Subversion if
there's a way to help with it's development.

-- Naked



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

Re: Special File Storage - Visions of grandeur

[Karl Fogel <kf...@newton.ch.collab.net>]

Nuutti Kotivuori <na...@iki.fi> writes:
> 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.
> 
> ***
> 
> So. Thoughts? :-)

My main thought right now is, can you attach your vision of grandeur
to the issue? :-)

The proposal looks good; we still need to know the user interface,
though.  For implementation I prefer your "straightforward" approach,
as a lot of factoring will get done naturally that way anyway.

I don't mean to be discouraging, but there are just too many other hot
issues right now, so we can't spend much time on special files support
(at least I can't, and the same is probably true for many other
developers).  It will be a great feature when we have it, but since
the latest proposal wonderfully does not require any libsvn_wc
redesign, that means we don't have to worry about painting ourselves
into a corner if we wait.

If you have usage scenarios and/or a working patch, there's no reason
they can't be committed when ready.  I'm just pointing out that you're
in the driver's seat if you want this to happen before 1.0 :-).

-K

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