> The 'name' is just some metadata stored within a user's working copy,
> to refer to some local edits that haven't yet been committed. Anyone
> using the particular working copy can see the name. However, it's not
> considered a good practice to have multiple users sharing a single
> working copy.
ok, but if you said something like:
svn commit (list of files) --name 'my_changeset'
wouldn't it be possible to store the named changeset on the server, rather than
relying on the number of the changeset?
Suppose I'm an administrator.
Someone checks in, on a branch, four changesets with:
svn commit --name 'my_changeset' a b c
svn commit --name 'my_changeset2' d e f
svn commit --name 'my_changeset3' g h i
svn commit --name 'my_changeset4' j k l
As an administrator, I now want to apply these changesets to the trunk. I don't
have access to the working copy of the developer who checked these in, and hence
don't have access to their metadata.
So how do I refer to these changesets if their names are not stored somewhere
on the server?
ie:
svn merge ???
> >And finally, how robust are the changesets?
> >
> >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?
>
>
> This scenario is fantasy. :-) Neither perforce nor subversion are
> able to associate a file with more than one changeset at a time.
> Sorry!
well, its not fantasy wrt Clearcase. At least that is their claim; that you
can create multiple changesets containing the same files. And I think that
bitkeeper may be able to do this as well, although I'm not sure about that.
And as long as the changesets are logically distinct, I don't see why this would
be impossible to do. I could see difficulties if someone, say:
1) modified a portion of the file in one changeset
2) modified the modification in another,
3) tried to merge in the later changeset but not the former
But if someone put a line at the beginning of the file in one changeset,
and put a line at the end of the file in another changeset, there's no reason
why these two changesets couldn't be applied separately.
To simplify things, at first you could maybe insist that these changesets be
applied in chronological order, but I see no reason why that should even
be an issue as long as one changeset doesn't depend on another.
>
> >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.
>
> Why does it matter to you? That's a curious request.
Because it gives an administrator/tech lead of a project a quick snapshot of
what everyone is working on and prevents 'orphan changes' - where someone
has worked on something in one tree and forgets about it.
Its not too much for to ask a source control tool to give you a road map
of what's going on, what has or has not been committed. I don't even think
it would be that bad, scalability-wise.
You'd just need a small daemon that runs locally, that polls for changes in
repositories, and when it finds a change, tells the server about it. The server
then stores it in *its* metadata, and when a checkin is done, removes the
difference from the database.
In fact, I think that this still respects your design as well as its
scalability; the client is still talking to the server on a per-need basis,
and the communication is only going from client to server.
Ed
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 12 21:08:01 2006