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

Re: Subversion in 2010

From: Mark Mielke <mark_at_mark.mielke.cc>
Date: Wed, 06 Jan 2010 21:26:24 -0500

On 01/06/2010 12:12 PM, Greg Hudson wrote:
> On Wed, 2010-01-06 at 11:16 -0500, Julian Foad wrote:
>
>>> * No commitment to mixed-revision working copies.
>>>
>> That sounds interesting, but I haven't got to grips with what it really
>> means in terms of user work flows, and in what senses it is an important
>> functional restriction versus an advantage.
>>
> If you want centralized-VCS-like workflow and don't have mixed-rev
> working copy support, you can wind up giving up automerge--the feature
> of Subversion that lets you commit your awesome new stuff without having
> to pull someone else's boring work in a different part of the tree
> first. For very active projects with commits every few minutes or more,
> that can be a big impediment.
>
> It may be possible for a system to work around this by having a "push
> and pull" operation such that you can push your changes and pull all of
> the non-conflicting changes at the same time. I don't know if that's at
> all common, though.
>

The "push and pull" sounds like a great idea to me - although this
should be "pull and push".

Mixed revision working copy introduces risk to the project. My working
copy works before my change, my working copy works after my change, but
somebody else who updates to my commit finds that their working copy no
longer builds successfully.

For large development projects with many developers and with imperfect
communication between project members, this sort of thing happens all
the time. For large projects under ClearCase, we use a "pull and push"
model (called "rebase" and "deliver"). For a project I use GIT on, I
actually use "git pull" and "git push". There is a race between the pull
and push whereby somebody who pushes before I pull will cause my push to
fail, but we generally consider this a good thing as it allows us to
analyze the change and determine whether additional testing is required
before we try to submit "pull and push" again.

The model is a bit easier to implement in ClearCase and GIT, since these
are both effectively the working copy is a different stream from the
parent whereas Subversion designer work flows tend to work directly on
"trunk".

I just wanted to point out that mixed revision working copies introduce
an additional element of risk for the project. It might be acceptable
risk, but it is additional risk over systems which do not provide the
"mix revision working copy feature".

Cheers,
mark

-- 
Mark Mielke<mark_at_mielke.cc>
Received on 2010-01-07 03:27:02 CET

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