Re: Merge Example in <version-goals-01221999.htm>

Sean Shapira (sds@jazzie.com)
Sat, 23 Jan 1999 16:14:56 -0800 (PST)


Message-Id: <m104DCa-000OW3C@jazzie.com>
From: sds@jazzie.com (Sean Shapira)
To: gclemm@tantalum.atria.com (Geoffrey M. Clemm)
Date: Sat, 23 Jan 1999 16:14:56 -0800 (PST)
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <9901232227.AA19135@tantalum> from "Geoffrey M. Clemm" at Jan 23, 99 05:27:46 pm
Subject: Re: Merge Example in <version-goals-01221999.htm>

Responding to some of Geoff's comments/questions in reverse order:

> Does this address your concerns?

Yes, I think it does.  Thanks!

> Joe doesn't claim the right to checkin on the mainline activity
> because he checked out the file first, but rather because he was the
> one working on the mainline activity when he did his checkout.  The
> assumption is that he is in the middle of making some consistent
> change to the mainline.

Joe started to make a change to to the mainline.  Then Jane started
to make a change to the mainline.  Something in the protocol forced 
Jane to create a separate activity for her work, whereas nothing in 
the protocol forced Joe to do so.

> If you want whoever gets done first to be able to check their work
> into the mainline, then you just make it policy that everyone does
> their work in some private activity, and then only work on the
> mainline when they are actually doing their merge.

This certainly suffices.  What advise would you give on where to 
implement this policy so that it is the automatic behavior of the 
system whenever anyone checks out any versioned resource?  Would 
it be enforced/facilitated by a special client?  A special server?  
If in the server, does the protocol allow the server to fail Joe's 
checkout because he didn't specify a new activity for his work, 
just as it failed Jane's checkout for this reason?

-- 
Sean Shapira         sds@jazzie.com         +1 206 443 2028