[OT] Conflict, an open source project

[Dennis Byrne <de...@apache.org>]

Hello svn devs,

I've started an open source project designed to notify svn users of
conflicts as they occur, rather than at commit time.  It works like this.
The Conflict client will publish the output from "svn diff" to the Conflict
server.  The Conflict server keeps track of which developer is working with
which resource.  When a conflict is detected, the server puts this in the
response.  The Conflict client then displays this to the developer (IDE
window, Windows tray icon, etc.).

Have any of you heard of anything like this before?  Am told perforce does
something similar.

One question, is the svn diff output *identical* to cvs diff output?  If so,
Conflict could be used with both.

I've completed an Eclipse plugin Conflict client, you can see what it does
here
http://notdennisbyrne.blogspot.com/2007/07/eclipse-rcp-client-for-conflict-and.html.

Feedback welcome. Let me know if you think svn users would find this useful,
or if you think it's a POS.

-- 
Dennis Byrne

Re: [OT] Conflict, an open source project

[Dennis Byrne <de...@apache.org>]

Well, thanks for "taking the gloves off", Ben and Malcolm.  I went and did
it anyways [1], so time will tell if people find this useful :)

[1] http://conflict.sourceforge.net

Dennis Byrne

On 8/3/07, Malcolm Rowe <ma...@farside.org.uk> wrote:
>
> On Thu, Aug 02, 2007 at 04:33:06PM -0500, Ben Collins-Sussman wrote:
> > The feature seems to be motivated by a deep desire to avoid
> > out-of-dateness (and conflicts) at all costs;  but this sort of goes
> > against the whole philosophy of the copy-modify-merge model.  So what
>
> (and it's worth mentioning that file-level locks don't help at all with
> the kind of semantic 'conflicts' that occur e.g. when someone else's
> refactoring renames a function that you depended upon in your current
> wc).
>
> Regards,
> Malcolm
>
>


-- 
Dennis Byrne

Re: [OT] Conflict, an open source project

[Malcolm Rowe <ma...@farside.org.uk>]

On Thu, Aug 02, 2007 at 04:33:06PM -0500, Ben Collins-Sussman wrote:
> The feature seems to be motivated by a deep desire to avoid
> out-of-dateness (and conflicts) at all costs;  but this sort of goes
> against the whole philosophy of the copy-modify-merge model.  So what

(and it's worth mentioning that file-level locks don't help at all with
the kind of semantic 'conflicts' that occur e.g. when someone else's
refactoring renames a function that you depended upon in your current
wc).

Regards,
Malcolm

Re: [OT] Conflict, an open source project

[Ben Collins-Sussman <su...@red-bean.com>]

On 8/2/07, Dennis Byrne <de...@apache.org> wrote:
> Hello Ben,
>
> > everyone's working copy, and only becomes read-write when you 'svn
> > lock' it.  Thus, you discover pre-existing locks *before* you even
> > begin to edit the file.
> 'svn:needs-lock' property on a file, then it becomes read-only in
>
> I wasn't aware of this.  I know this is a question more appropriate for the
> user list, but you are saying the svn server keeps track of who has locked
> what?

Sure, how else could the server enforce the lock, if it isn't tracking
locks?  :-)
Read the section about 'locking' in the online svnbook for a complete
explanation of how the system works.  It's very similar to what you're
already proposing.  (Though, we only recommend it for files that
*must* be edited serially, like big binary formats, which can't be
merged together.)

>
> > Regarding your conflict-server idea:  perforce solves the problem by
> > keeping *all* working copy files as read-only.  You need to 'p4 edit'
> > a file to make it read-write, at which point the server then keeps
> > track of exactly which files you're editing.  You can ask the server
> > (at any point) who is working on a file.
>
> In a similar vein, is there demand from the user community to know when a
> file is stale once the user begins to edit it?  In other words, I think it
> would be nice to notify a dev if they are not working with the latest
> revision.  Currently Conflict does not do this, but is in a realistic
> position to do

I'm not sure if there's demand for your feature.  Certainly, we've had
12+ years of CVS and Subversion lacking this feature, and I've never
heard of anyone asking for it.

The feature seems to be motivated by a deep desire to avoid
out-of-dateness (and conflicts) at all costs;  but this sort of goes
against the whole philosophy of the copy-modify-merge model.  So what
if two people edit the same file at once?  You merge, and deal with
conflicts.  If conflicts are happening on a daily basis, then the team
is somehow failing to communicate effectively;  it's a problem best
solved socially, rather than via a central database trying to
technologically make people aware of each other's actions.

Furthermore, the whole open source world has lately been moving toward
decentralized version control systems, which is even *more*
loosey-goosey in terms of people working simultaneously on the same
files.  These systems don't just eschew merges and conflicts, they're
entirely *built* around the assumption of frequent merging.  As these
systems get more popular, it seems like an argument (in my mind) that
there's less and less demand to solve the problem you're trying to
address!

I don't want to dissuade you from working on scratching an itch you
think is interesting, but I thought you might at least want to hear
some arguments as to why the itch may not be very relevant to most
users.  :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [OT] Conflict, an open source project

[Dennis Byrne <de...@apache.org>]

Hello Ben,

everyone's working copy, and only becomes read-write when you 'svn
> lock' it.  Thus, you discover pre-existing locks *before* you even
> begin to edit the file.

'svn:needs-lock' property on a file, then it becomes read-only in

I wasn't aware of this.  I know this is a question more appropriate for the
user list, but you are saying the svn server keeps track of who has locked
what?

Regarding your conflict-server idea:  perforce solves the problem by
> keeping *all* working copy files as read-only.  You need to 'p4 edit'
> a file to make it read-write, at which point the server then keeps
> track of exactly which files you're editing.  You can ask the server
> (at any point) who is working on a file.


In a similar vein, is there demand from the user community to know when a
file is stale once the user begins to edit it?  In other words, I think it
would be nice to notify a dev if they are not working with the latest
revision.  Currently Conflict does not do this, but is in a realistic
position to do

A number of people have requested a similar mode of operation for
> subversion, since it would solve the same problem your conflict-server
> does.


I'll go off and make this happen.  I'll post back here with the results as
long as your team does not mind the noise.  Thanks.

---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>


-- 
Dennis Byrne

Re: [OT] Conflict, an open source project

[Ben Collins-Sussman <su...@red-bean.com>]

On 8/2/07, Dennis Byrne <de...@apache.org> wrote:

> I see this as an alternative to locking.  In my experience, it is not as
> used as much as some of the other great features in subversion.  Also, it's
> my understanding that you will not know about the lock until it is time to
> commit your changes.

Actually, no, that's not the case at all.  If you put the
'svn:needs-lock' property on a file, then it becomes read-only in
everyone's working copy, and only becomes read-write when you 'svn
lock' it.  Thus, you discover pre-existing locks *before* you even
begin to edit the file.

Regarding your conflict-server idea:  perforce solves the problem by
keeping *all* working copy files as read-only.  You need to 'p4 edit'
a file to make it read-write, at which point the server then keeps
track of exactly which files you're editing.  You can ask the server
(at any point) who is working on a file.

A number of people have requested a similar mode of operation for
subversion, since it would solve the same problem your conflict-server
does.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [OT] Conflict, an open source project

[Dennis Byrne <de...@apache.org>]

Hey Charles,

I've never had a chance to work on perforce, but I'm skeptical toward
> *when* the Conflict client would query or publish data to the Conflict
> server.  Do you manually have to query the server to receive those
> updates?  Or is it set as an option when running another command like
> "svn/cvs update"?  When do you send your updates to the server in
> turn?


 Yes, this is the number one question I've been asked so far.  The
query/publish is based upon how smart the Conflict client is.  The only one
I've completed, the Eclipse plugin, is time based.  It polls using a
configurable interval setting.  Next up on my plate is a .Net Windows
service.  This will allow me to write a smarter client that can hook into
file system events. One day I'll get around to figuring out how subclipse is
getting it's info.  Does anyone here know?

Querying the server happens when the update/report happens as well. It's
lower priority, but I want to split these two, since it is pretty cheap for
the server to calculate a conflict list.

I can't guaranty it is 100% identical, but I'm sure there are lots of
> folks on this list who have this answer.  However, svn diff is using
> Unidiff and so is cvs.


Good, I was hoping someone here could confirm this.

I'm just wondering how different is it from using lock-mechanism if
> not granularity?  (lock is dealing with paths, or files, Conflict with
> lines? bytes?)


I see this as an alternative to locking.  In my experience, it is not as
used as much as some of the other great features in subversion.  Also, it's
my understanding that you will not know about the lock until it is time to
commit your changes.  As a dev, I'd rather know when I stepped on someone
else's toes within a half hour.  I am on a lot of Scrum/XP projects.
There's a big emphasis on common code ownership, so locking isn't popular.

Cheers,
> Charles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>


-- 
Dennis Byrne

Re: [OT] Conflict, an open source project

[Daniel Rall <dl...@finemaltcoding.com>]

On Aug 2, 2007, at 2:30 AM, Charles Acknin wrote:
...
> On 8/2/07, Dennis Byrne <de...@apache.org> wrote:
...
>> One question, is the svn diff output *identical* to cvs diff  
>> output?  If so,
>> Conflict could be used with both.
>
> I can't guaranty it is 100% identical, but I'm sure there are lots of
> folks on this list who have this answer.  However, svn diff is using
> Unidiff and so is cvs.

The diff output is not identical, but it close.  Both can be fed to  
'patch'.  'cvs diff' requires the
'-u' option to go into unidiff format, while unidiff is the default  
for Subversion's built-in diff.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [OT] Conflict, an open source project

[Charles Acknin <ch...@gmail.com>]

Hey Dennis,

On 8/2/07, Dennis Byrne <de...@apache.org> wrote:
> Hello svn devs,
>
> I've started an open source project designed to notify svn users of
> conflicts as they occur, rather than at commit time.  It works like this.
> The Conflict client will publish the output from "svn diff" to the Conflict
> server.  The Conflict server keeps track of which developer is working with
> which resource.  When a conflict is detected, the server puts this in the
> response.  The Conflict client then displays this to the developer (IDE
> window, Windows tray icon, etc.).
>
> Have any of you heard of anything like this before?  Am told perforce does
> something similar.

I've never had a chance to work on perforce, but I'm skeptical toward
*when* the Conflict client would query or publish data to the Conflict
server.  Do you manually have to query the server to receive those
updates?  Or is it set as an option when running another command like
"svn/cvs update"?  When do you send your updates to the server in
turn?

> One question, is the svn diff output *identical* to cvs diff output?  If so,
> Conflict could be used with both.

I can't guaranty it is 100% identical, but I'm sure there are lots of
folks on this list who have this answer.  However, svn diff is using
Unidiff and so is cvs.

> Feedback welcome. Let me know if you think svn users would find this useful,
> or if you think it's a POS.

I'm just wondering how different is it from using lock-mechanism if
not granularity?  (lock is dealing with paths, or files, Conflict with
lines? bytes?)

Cheers,
Charles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org