Stefan Kueng wrote: > A few more thought, mostly for the next release: > > * svn_client_shelf_save_new_version3 takes two callback functions, but > they both have the same type. So why not just change that API to take > one callback but provide a 'failed' flag instead?
Could do! I suppose that would mean less boilerplate code for you (the client) to write. > * when a shelve operation fails, we have to remove the version with > svn_client_shelf_delete_newer_versions. But if there are no more > versions left, the shelf itself is not removed. So while testing I ended > up with several empty shelves. I'm now using > svn_client_shelf_get_all_versions to count how many versions are left > and if there are none I'm calling svn_client_shelf_delete. I think > svn_client_shelf_delete_newer_versions should do that automatically. > Unless of course there's a reason why empty shelves can exist? I'm not entirely happy with the current relationship between a "shelf" object as a container of "shelf version" objects. At the moment a "shelf version" can only exist as a child of a "shelf". It is intentional that you can have a shelf that has no versions. It can still have a log message. (The user might want to name their shelf and write their log message before they start coding, for example, but that isn't a compelling use case.) I am considering partly inverting the relationship so a single-version shelf would be the primary object and a series-of-versions (for checkpointing and rollback) would be a higher level object that is a collection of single-version shelf objects. What do you think? > * maybe this one can make it into 1.11: the doc comments don't mention > that the version numbers are 1 based, not 0 based. [...] Thanks. I'll add it. > * some thoughts [...] you first have to open/create the shelf, save the new > version and close the shelf. [...] I would expect one API call [like] > svn_client_shelf(shelveName, wcPath, logMsg, depth, keeplocal); > and it would do everything automatically. I agree access to a higher level API would be useful, and I'll make a mental note to add that. At the same time I think it's essential that clients do have access to the lower-level building blocks of the operation, in order to build more interesting and different variants from what I implemented for the command-line client. So I would like to provide two levels of API. You won't then have to user the lower-level APIs if you don't want to, but any third-party who wants to innovate on the idea will then have the tools to do so. > in case you're interested, here are screenshots of the shelve and > unshelve dialog I did in TSVN: > https://svn.osdn.net/svnroot/tortoisesvn/trunk/doc/images/en/Shelve.png > https://svn.osdn.net/svnroot/tortoisesvn/trunk/doc/images/en/Unshelve.png Thanks for sharing those! -- - Julian
