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

Re: [OT] Conflict, an open source project

From: Dennis Byrne <dennisbyrne_at_apache.org>
Date: 2007-08-02 14:36:53 CEST

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
Received on Thu Aug 2 14:35:23 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.