Conflict, an open source project

Hey Dennis,

On 8/2/07, Dennis Byrne <dennisbyrneapache.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 8/2/07, Dennis Byrne <dennisbyrneapache.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 8/2/07, Dennis Byrne <dennisbyrneapache.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

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

On Aug 2, 2007, at 2:30 AM, Charles Acknin wrote:
...
> On 8/2/07, Dennis Byrne <dennisbyrneapache.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org