Re: thoughts about shelving

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