On 10/12/06, Ben Collins-Sussman <sussman@red-bean.com> wrote:
>
> On 10/12/06, Ed S. Peschko <esp5@pge.com> wrote:
> > (
> > 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.
...and with a full time administrator too :-)
> 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.
I was wondering the same thing but I sort of see this happening in
my group - mainly because of certain engineers' hesitance to make
branches and check in code. There are some multi-month development
efforts (changes/updates) that have never been checked in anywhere
and the code being passed around manually to the other engineers
that depend on the new code.
A lot of this may be due to past poor tool sets and thus learned behaviors
that do not really make sense.
Knowing what a developer has changed locally - for whatever reason - is
usually not productive and can actually be counter-productive (especially
when it is a trial-balloon type of change or hack to test something).
However,
if the behavior is like I described above, then what is really going on is
trying to make the tool work around bad behavior.
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.
Actually, I have pushed to change-set reviews but this is done within
a short-lived branch. The branch is then destroyed once merged.
This has the added benefit that the change set can be worked on
by more than one person and the review of the changes is rather
easy as it is exactly the same process as the review of a patch or merge.
(This is mainly for larger changes - a spelling change or other such
minor thing usually does not go through the same level of code review)
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
Received on Thu Oct 12 14:25:50 2006