On Wed, Oct 11, 2006 at 08:47:31PM -0500, Ben Collins-Sussman wrote:
> On 10/11/06, Ed S. Peschko <firstname.lastname@example.org> wrote:
> >hey all,
> >I was wondering - how are named changesets implemented in subversion? We
> >are looking
> >at (amongst others) subversion and perforce, and this seems to be a
> >feature that we
> >couldn't really live without.. Basically I'd like to say:
> > svn commit --name=<changeset_name>
> Perforce tracks all changesets on the server. Subversion doesn't do
> that; the server doesn't track any sort of client data whatsoever.
> However, a subversion client *does* have simple bookkeeping that
> allows you to define and name changesets, and commit them exactly as
> you show above.
> >and at a later point, say something like
> > svn merge --name=<changeset_name> --branch=HEAD
> Once you commit to subversion, the commit gets a permanent changeset
> name in the server, just a large integer. When you want to merge a
> changeset from one branch to another, you just use the changeset
> number. So yeah, it's pretty darn close to what you're showing.
first of all, thanks for the reply.. I'm just curious though,
if there is a number stored somewhere that represents a changeset,
it would seem trivial to give an option to the commit to make an
alias of a name for that number on the server side..
I'm also curious - you said that there are numbers associated with
changesets. Are they stored on the client as well, or on the
server? Since the names are stored on the client, I'm assuming that
an administrator can't use the same name to reference the changeset
as the client does... Is this right?
And finally, how robust are the changesets?
Here's an example of what I have in mind - suppose developer
X creates four files (A B C and D). X then makes three changesets
to those files, done in the following order:
Now suppose (s)he wants to merge changeset #1 into the
repository, without merging #2 or #3. Is it possible to merge
*just* the A,B, and D changes in #1 without touching the
changes in #2 and #3?
ps - is the rule about the server not tracking any of the
client data a rock solid one?
eg: One of the things that *really* bothers me about CVS
as an administrator is the fact that you have no way of knowing
who has changed what locally.
However, I don't want to force people to atomically lock everything
in order to get an idea of what is going on on other people's
I'd like a way to query individual clients who have talked to my
server, and see if any non-committed changes still exist out there.
I think perforce can do this; are there any plans on adding this type of
functionality (maybe a daemon to send this info back to the server). Or
is it easy to write your own daemons that could do something like this?
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Oct 12 09:15:10 2006