[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Poor performance in windows. Switching back to CVS

From: Jeff Smith <jsmith_at_robotronics.com>
Date: 2007-02-16 15:47:34 CET

On Thursday 15 February 2007 20:31, Les Mikesell wrote:
> Jan Hendrik wrote:
> > The point, however, is that *all* FTP synching has to done from
> > the *same* WC - all the other WCs have timestamps different from
> > those on the webserver (checkout/commit time).
>
> I'd be even more extreme about this and use that WC only for
> staging. That is, never edit or commit from there. Instead,
> edit/commit from other working copies then update this WC, do any
> final testing you might do, and push to production. That not only
> avoids timestamp issues, but it eliminates the possibility of
> putting something in production that you had changed locally and
> not committed - which can lead to not being able to back out the
> next change, should the need arise.

I suppose Jan means they all FTP-sync to one group server which has
the svn client... Howabout rather than having only one "group WC" on
that server, everyone have a seperate WC there so each syncs only
with their own. Maybe not since one WC has a huge number of files.

Well, to me, this keeps comming back to two rules for using
subversion, which should never be impossible to meet:

1. Each developer must have their own svn WC (subversion working
copy). I still saw no reason why you cannot each have, on your own
PC, an svn client which can be secured just as much as any other form
of file transfer.

2. Each developer should only check out the part of the project they
are working on. At least I have never seen a project where each
member of the team must constantly work on 10,000 files at once. They
have always been broken up into categories (by subdir) so that one
week I might be working only on the "drivers/wheel" component.

Planning the structure like this is crucial, esp. if we know we will
have a huge number of files to manage.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 16 15:48:29 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.