Work on the WC class is finally moving at a good pace. At this point, the WC actually supports some useful operations (such as diff-ing), and the ctypes bindings are feeling more and more complete. Still a long way to go.
Currently I have two main goals: add well written test cases for everything and find out why failures in commits and updates are so catastrophic. With the current bindings, if a commit or update fails, it doesn't produce an error (as it should) it results in a segmentation fault.
The coming week will be primarily for completing the WC class and adding formal tests.
Thursday, July 5, 2007
Thursday, June 14, 2007
Just a quick update about my work on the WC class. Probably the best way to summarize is to post the patch I just sent to the mailing list:
This patch adds a class representing the WC to the new python bindings. At present, it's a somewhat rough patch, but it does include some basic functionality.
Here's a rundown of the wc class, as it stands:
WC(path):Creates a new WC object for the working copy located at PATH. PATH defaults to the present working directory.
WC.info(): Returns a string with the same contents as 'svn diff' on the command line. Not critical, but useful.
WC.has_conflict(): If the WC has a conflict, return en entry for the conflicted file. Otherwise return False.
WC.delete(path): Schedules PATH for deletion in the next update.
WC.add(path): Schedules PATH for addition.
WC.copy(src,dest): Copies SRC to DEST, DEST will be scheduled for addition in the next revision.
WC.move(src,dest): Moves SRC to DEST. SRC will be deleted and scheduled for deletion, DEST will be scheduled for addition.
WC.revert(path, recurse, commit_time): Revert PATH. If RECURSE is true, directories will be recursed. If COMMIT_TIME is true, the last changed time will be changed to the commit time. RECURSE and COMMIT_TIME are True by default.
WC.revert_all(show_hidden): Revert everything in the wc. If SHOW_HIDDEN is true, hidden files will be reverted too. SHOW_HIDDEN is False by default.
WC.resolve(path): Resolve a conflict on PATH. Not thuroughly tested as of yet.
WC.text_modified(path): Returns True if the text of PATH has been modified.
WC.prop_modified(path): Returns True if the props of PATH have been modified.
WC.wc_entry(path, show_hidden): Returns an entry for PATH. If show_hidden is True (which it is by default), can generate an entry for a hidden file.
WC.is_scheduled_add(path): Returns True if PATH is scheduled for addition.
WC.is_scheduled_delete(path): Returns True if PATH is scheduled for deletion.
WC.diff_path(modified): Returns a string containing a diff of MODIFIED and it's original version. At present, only works for files that are in the repository (not files marked for addition).
svn_kind_to_string(kind): Convert an entry kind to a human-readable string.
svn_schedule_to_string(schedule): Convert an entry schedule to a human-readable srting.
A little more information about these functions can be found inline in wc.py.
I've also included wcexample.py, a simple example/test of the wc functionality. It's designed to be run in place, change a few things, and then revert the changes that it made.
[[[
Add a working copy class to the ctypes python bindings.
wc.py(WC, WC.info(), WC.text_modified(), WC.prop_modified(), WC.has_conflict(), WC.copy(), WC.move(), WC.delete(), WC.add(), WC.resolve(), WC.revert(), WC.revert_all(), WC.wc_entry(), WC.is_scheduled_add(), WC.is_scheduled_delete(), WC.diff_path(), svn_kind_to_string(), svn_schedule_to_string()): WC class and methods to handle simple operations.
]]]
This patch adds a class representing the WC to the new python bindings. At present, it's a somewhat rough patch, but it does include some basic functionality.
Here's a rundown of the wc class, as it stands:
WC(path):Creates a new WC object for the working copy located at PATH. PATH defaults to the present working directory.
WC.info(): Returns a string with the same contents as 'svn diff' on the command line. Not critical, but useful.
WC.has_conflict(): If the WC has a conflict, return en entry for the conflicted file. Otherwise return False.
WC.delete(path): Schedules PATH for deletion in the next update.
WC.add(path): Schedules PATH for addition.
WC.copy(src,dest): Copies SRC to DEST, DEST will be scheduled for addition in the next revision.
WC.move(src,dest): Moves SRC to DEST. SRC will be deleted and scheduled for deletion, DEST will be scheduled for addition.
WC.revert(path, recurse, commit_time): Revert PATH. If RECURSE is true, directories will be recursed. If COMMIT_TIME is true, the last changed time will be changed to the commit time. RECURSE and COMMIT_TIME are True by default.
WC.revert_all(show_hidden): Revert everything in the wc. If SHOW_HIDDEN is true, hidden files will be reverted too. SHOW_HIDDEN is False by default.
WC.resolve(path): Resolve a conflict on PATH. Not thuroughly tested as of yet.
WC.text_modified(path): Returns True if the text of PATH has been modified.
WC.prop_modified(path): Returns True if the props of PATH have been modified.
WC.wc_entry(path, show_hidden): Returns an entry for PATH. If show_hidden is True (which it is by default), can generate an entry for a hidden file.
WC.is_scheduled_add(path): Returns True if PATH is scheduled for addition.
WC.is_scheduled_delete(path): Returns True if PATH is scheduled for deletion.
WC.diff_path(modified): Returns a string containing a diff of MODIFIED and it's original version. At present, only works for files that are in the repository (not files marked for addition).
svn_kind_to_string(kind): Convert an entry kind to a human-readable string.
svn_schedule_to_string(schedule): Convert an entry schedule to a human-readable srting.
A little more information about these functions can be found inline in wc.py.
I've also included wcexample.py, a simple example/test of the wc functionality. It's designed to be run in place, change a few things, and then revert the changes that it made.
[[[
Add a working copy class to the ctypes python bindings.
wc.py(WC, WC.info(), WC.text_modified(), WC.prop_modified(), WC.has_conflict(), WC.copy(), WC.move(), WC.delete(), WC.add(), WC.resolve(), WC.revert(), WC.revert_all(), WC.wc_entry(), WC.is_scheduled_add(), WC.is_scheduled_delete(), WC.diff_path(), svn_kind_to_string(), svn_schedule_to_string()): WC class and methods to handle simple operations.
]]]
Monday, June 4, 2007
Update 3: More on the WC class
Got a few (much more useful) features added to the wc class, including add, revert, delete, and a few more methods for getting various elements of the current state. I also had a working copy, before some unknown change made it not work.
My present work on the wc class is mostly guided by the idea that I want to finish the functions I'm most likely to use first. Add, revert, delete, and so on are some of the most common actions I take on a working copy, so I'm using those as a starting point for further work.
From here, I continue adding important methods to the wc class, as well as making it more user friendly and efficient. I've also updated my test script to be more useful and more formal, and I plan to continue to improve that as more features are added that need tests. I think I should have a solid enough version of wc to patch into the repository sometime this week. I want to make sure my work is solid before it gets subjected to too much review, but what I have now is at least a good start.
My present work on the wc class is mostly guided by the idea that I want to finish the functions I'm most likely to use first. Add, revert, delete, and so on are some of the most common actions I take on a working copy, so I'm using those as a starting point for further work.
From here, I continue adding important methods to the wc class, as well as making it more user friendly and efficient. I've also updated my test script to be more useful and more formal, and I plan to continue to improve that as more features are added that need tests. I think I should have a solid enough version of wc to patch into the repository sometime this week. I want to make sure my work is solid before it gets subjected to too much review, but what I have now is at least a good start.
Friday, June 1, 2007
Update 2: Minor Updates, Renames, and the Beginning of WC
Done this week:
Some minor updates and renames to the existing ctypes python bindings, with the aim of making names and files logical. Changed things like "client" to "repository" to make it clear what it really is, moved helper functions out of client.py, etc.
Also this week, I started work on the wc class for the ctypes binding. At this point, I have three methods working more or less completely, those being:
text_modified - checks the status of a given path in the working copy to see if the text has been modified
prop_modified - just like text_modified, but for props.
has_conflict - check for conflicts in the given path. This is slightly incomplete, in that it doesn't yet identify the kind of conflict.
I don't have extensive test cases written for these yet, but I do have some simple tests to give me an idea what's working. Once I got past some of the basic problems of moving from reading code ment to work with ctypes to writing code to work with ctypes, things have started moving more smoothly.
Next week, I plan on continuing minor updates to the existing code while putting wc.py into good enough shape to be added to the repository. I also plan on writing more complete tests, and making automated tests for existing functionality.
Some minor updates and renames to the existing ctypes python bindings, with the aim of making names and files logical. Changed things like "client" to "repository" to make it clear what it really is, moved helper functions out of client.py, etc.
Also this week, I started work on the wc class for the ctypes binding. At this point, I have three methods working more or less completely, those being:
text_modified - checks the status of a given path in the working copy to see if the text has been modified
prop_modified - just like text_modified, but for props.
has_conflict - check for conflicts in the given path. This is slightly incomplete, in that it doesn't yet identify the kind of conflict.
I don't have extensive test cases written for these yet, but I do have some simple tests to give me an idea what's working. Once I got past some of the basic problems of moving from reading code ment to work with ctypes to writing code to work with ctypes, things have started moving more smoothly.
Next week, I plan on continuing minor updates to the existing code while putting wc.py into good enough shape to be added to the repository. I also plan on writing more complete tests, and making automated tests for existing functionality.
Monday, May 21, 2007
Update 1: All Is Not Well In Mac Land
First of all, a few words on this blog: the idea here is to provide ~weekly (more often as needed) updates on my progress with updating the python bindings for the subversion API. My original proposal can be found on the SoC site, but beware that some details have changed since then, as per discussion on th mailing list.
At present the code base is just as my mentor, David James, left it. I have been planning how the final binding should look and work, which has been more challenging then I thought. I've never planned something quite so broad as this before, most of my design work has been much narrower in scope. I looked at existing bindings, as well as some of the Perl packages on CPAN, to get some ideas of how the final bindings should work. My design philosophy at present is to abstract away as much as possible, giving the API programmer an interface similar to what they would have through command line tools.
In the process of studying David's existing ctypes work, I found that at present the autogen system will not work on Mac. I had been working remotely on a linux box, where the system worked well enough, but some issues made me move development to my MacBook, on which the system to autogenerate ctypes bindings does not work. I've encountered one error I've identified and one that has me stumped.
First the one I've figured out: the yacc.py stuff used to parse C files as part of building the bindings does not like a few features that are used in some of the standard Mac libraries (byte order stuff mostly), including keywords like 'inline' and a few other things (bool values, some preprocessor directives, etc.). My present workaround is to create temporary duplicates that avoid the features that don't parse as best I can.
Even with all these files parsing correctly, I still have issues with some functions apparently not making it into the ctypes binding. Haven't figured this out yet, but I'm working on it.
I was hoping to have a complete design document today, but I feel that what I have is a little incomplete. I'm going to be in contact with my mentor this week to try to complete this design. I'm also planning on implementing a few incremental upgrades that James suggested for me. These are(quote from email):
- Rename ClientSession to RemoteRepository
- Rename LocalClient to LocalRepository
- Rename ClientURI to RepositoryURI
- Move helper classes in client.py into a different file, not sure
of the name yet
- Rename client.py to repository.py, so as to make clear that it's
intended for direct repository access
- Replace '@staticmethod' attributes from csvn/core/__init__.py
with Python 2.3-compatible syntax
- Write some documentation on how to run the mucc-test.py test suite.
Most of these changes are fairly straightforward (I've actually already done a few, but I can't really call them complete since I can't run the tests to make sure they work, see above about the problems I'm having). I think they'll give me a good chance to get some hands on hacking experience, since as of yet I've mostly just messed around with added print statements so I can track the control flow.
At present the code base is just as my mentor, David James, left it. I have been planning how the final binding should look and work, which has been more challenging then I thought. I've never planned something quite so broad as this before, most of my design work has been much narrower in scope. I looked at existing bindings, as well as some of the Perl packages on CPAN, to get some ideas of how the final bindings should work. My design philosophy at present is to abstract away as much as possible, giving the API programmer an interface similar to what they would have through command line tools.
In the process of studying David's existing ctypes work, I found that at present the autogen system will not work on Mac. I had been working remotely on a linux box, where the system worked well enough, but some issues made me move development to my MacBook, on which the system to autogenerate ctypes bindings does not work. I've encountered one error I've identified and one that has me stumped.
First the one I've figured out: the yacc.py stuff used to parse C files as part of building the bindings does not like a few features that are used in some of the standard Mac libraries (byte order stuff mostly), including keywords like 'inline' and a few other things (bool values, some preprocessor directives, etc.). My present workaround is to create temporary duplicates that avoid the features that don't parse as best I can.
Even with all these files parsing correctly, I still have issues with some functions apparently not making it into the ctypes binding. Haven't figured this out yet, but I'm working on it.
I was hoping to have a complete design document today, but I feel that what I have is a little incomplete. I'm going to be in contact with my mentor this week to try to complete this design. I'm also planning on implementing a few incremental upgrades that James suggested for me. These are(quote from email):
- Rename ClientSession to RemoteRepository
- Rename LocalClient to LocalRepository
- Rename ClientURI to RepositoryURI
- Move helper classes in client.py into a different file, not sure
of the name yet
- Rename client.py to repository.py, so as to make clear that it's
intended for direct repository access
- Replace '@staticmethod' attributes from csvn/core/__init__.py
with Python 2.3-compatible syntax
- Write some documentation on how to run the mucc-test.py test suite.
Most of these changes are fairly straightforward (I've actually already done a few, but I can't really call them complete since I can't run the tests to make sure they work, see above about the problems I'm having). I think they'll give me a good chance to get some hands on hacking experience, since as of yet I've mostly just messed around with added print statements so I can track the control flow.
Subscribe to:
Posts (Atom)
