Julian,
>Julian Foad wrote:
>
> This is not a simple task but if you tackle it in stages, discussing
> each stage here on this mailing list, it should be possible. The work
> should be done and reviewed and committed as a series of functional
> stages, too, not as one big patch that implements the whole thing, as
> that change would be too complex.
>
> I would like to see this feature become reality so thank you for working
> on it.
> How would you like to start?
>
> - Julian
to answer your last question, I made a quick draft of the things I plan to do.
My first step on this issue is to read and learn the relevant code. While I've
spent a lot of time as Subversion admin and did some bugfixing here & there, a
lot of the C code is new terrain for me. I'm working on that.
It seems there are two parts in this feature request then:
- cleanup of libsvn_wc by tunneling all read & write access on working copy
files through one interface
- extend the implementation of that interface with (de-)compression
functionality.
I want to handles this parts one by one, according to (roughly) these steps:
1. Identify all problem areas in libsvn_wc
a. identify all read access to the working copy
b. identify all write access to the working copy
2. Find read & write access to the wc in other libraries
( at the same time I'll get a basic idea of the code structure and where to find
what )
3. Define a basic interface for reading & writing ( using streams presumably )
a. choose the best abstraction level
b. choose place where to put interface & implementation
c. verify that all the places where this interface will be used will be using
the standard implementation, possibly there are some exceptions.
Now, either I can go on and implement that interface, change all other code to
use that new interface and make that stable. Or, I could first discuss all needs
for the compression feature here on the list, because possibly the new
interface needs to be extended.
4. Discuss the compression feature. Points to be raised:
a. how can the user configure when to use compression? -> define all
use-cases.
- define for the whole working copy, or folders
- limit compression to certain extensions only
b. where are these settings stored
c. what's the abstraction level of the interface, what does the client code
need to know about compression of the wc.
d. how do we mark a file as compressed ( .gz/zip, in entries file, .zvn
folder, svn-zbase etc. )
e. what other request are there to be fullfilled as well ( optional
text-base, other places of storage ... )
-> a document can be made here in which the discussion is summarized and final
decisions are logged.
5. At this point, the design of the new feature can be made:
a. the new file access interface might be extended with compression specific
parameters/functions
b. which functions do we need
c. where do I put the new code
6. Implementation - 1
a. extract common code for reading & writing to wc files in implementation of
new interface
b. make libsvn_wc use the new interface ( ignore compression for now )
c. make all other subversion parts use this interface
d. check unit tests, this part should be stable on its own
7. Implementation - 2
a. add compression to implementation of interface
b. add decompression to implementation of interface
c. add new unit tests to test the new features
Now this may be a long list, and probably not all the steps are in either,
but I think a lot of the ground has already been covered by previous
discussions and the large patch that has been circulating here for over
2 years. I plan not to start all over, but will try to consolidate previous
discussion or open new where needed.
I'm not uptodate concerning other features that might have an impact on this
one, so any input on that is appreciated.
What would be the best branch to start with? I prefer to start from
branches/1.2.x, or is it better to start from trunk?
Any input is appreciated.
Lieven.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 7 17:16:09 2005