John wrote:
> I've been reading about the 'shelveset' feature of the new Visual Studio
> Team System, and wondering how the same could be achieved in SVN - without
> branching.
>
> Quick overview: a VSTS shelveset is basically a patch file stored in the
> repository (unversioned). Other people can apply it to their WC's, comment,
> improve etc (permissions allowing). You can optionally revert your WC
> following production of a shelveset (that's were the name comes from,
> shelving work).
>
> Now SVN does all this stuff, kinda. And I'm not sure it's really SVN's role
> to manage unversioned patch files (is it??). But I think it would be really
> great to achieved this functionality, either using script files (and maybe
> an ftp server?), extension of the client, or even some new storage
> mechanism on the svn server.
First thing that strikes me here is that the patch is stored unversioned. In
my eyes, there's no use for that: it is work in progress that should for sure
be versioned.
In order to store versioned patches (is this btw the same that bitkeeper
refers to as changesets?) there are three ways:
1. Store a patchfile - no comments on this, its (dis-)advantages are all
known.
2. Branch the project. Here, the patch is the difference from the point of
branching to the current head in the branch.
3. Use Subversion's extended patch format which also handles metainfo, binary
files etc. There is already a tracker-item requesting this format be finally
implemented, but until then it just is a nice dream. Sorry.
So, considering the status quo, I'd suggest going for idea 2. However, one
should perhaps introduce a fourth folder next to trunk/tags/branches called
changesets or patches. That way, people would understand that these are just
single features that can be merged into workingcopies.
> Hmm, if we used the perl / python, can either language create graphical
> dialogs, asking for comments etc? I'd like something pretty looking :)
Sure. Python even has native bindings to Subversion, so that would be a good
start for integration.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 3 09:32:28 2005