On 10/12/06, Ed S. Peschko <esp5@pge.com> wrote:
> 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?
The numbers are immutable names for changesets, and they exist only in
the server after a changeset has been committed. The client can refer
to them, of course, when asking for server data.
> 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?
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.
>
> 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:
>
> Changeset #1:
>
> modifies A
> modifies B
> modifies D
>
> Changeset #2:
>
> modifies B
> modifies C
> modifies D
>
> Changeset #3:
>
> modifies A
> modifies B
> modifies C
>
> 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!
>
> Thanks again,
>
> Ed
>
> (
> ps - is the rule about the server not tracking any of the
> client data a rock solid one?
Yes, that's what makes subversion scalable to thousands of users over
a WAN. Perforce is great, but is really only designed for a fast LAN.
> 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.
FYI: if you use perforce, and everyone checks out working copies into
shared NFS home directories, then you *can* ask the perforce server to
show changesets-in-progress to you which belong to other people. But
the NFS bit is key.
> 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?
No plans to do this. The only advantage of this feature is that it
makes it easy to review your neighbor's changeset. Instead of having
them post a patch to a mailing list for review, you can ask perforce
to just show you your neighbor's changeset. It makes the code review
process a touch nicer. But subversion is an inherently disconnected
system; it would really violate the spirit and design to have the
subversion server do any sort of client-side tracking.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 12 14:04:20 2006