mark benedetto king <mbk@lowlatency.com> writes:
> On Tue, Sep 23, 2003 at 03:15:44AM +0000, Files wrote:
> > Suggestions on how to deal w/ two disparate build environments where I might be
> > working on subversion and conveying the changes across???
> >
> > Thanks.
>
> svn diff | ssh otherhost "cd /path/to/wc; patch -p0"
Right.
Remember, Shamim, that a working copy *is* a branch. It's just a
private one. You can have as many working copies as you want, and do
as many 'experiments' as you want in them. And you won't be spamming
all the other developers with your in-between work. As Sander said:
we take commits seriously. Dozens of developers read commit-mails
with the assumption that they represent important changes.
Subversion is not like Clearcase or Perforce: we don't do *all* of our
work on the server, no matter how cheap branches are. There's an
attention-cost (of other developer's time) when you commit to the
server. The repository is considered the place where *final* changes
are saved, so that everyone can review them... not a place for
continuous scratchwork.
If you're working on a single comprehensible task -- and it's one that
no other developers want/need to watch -- do it in working copies,
then commit the final result, and let others comment.
On the other hand, if you're working on a task that's going to take
weeks of iteration, and you need other developers to *continuously*
review the progress of your code, then create a branch, and commit in
well-thought out stages.
In this case, I think most svn developers *don't* care about the
minute steps you're taking to develop Mandrake RPMs, so your work
falls into the 1st category -- it's private scratchwork. Examples of
the 2nd category (in the past) have been -- say, a gradual
reorganization of our repository filesystem db schema. It takes a
very long time, and everyone wants to watch.
Does this make things clearer, Shamim?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 23 15:25:00 2003