[news.eclipse.technology.epf] Re: EPF and Subversion/Subclipse

["Mark Phippard" <markphip@xxxxxxxxx>]

Scott wrote:

> We quickly realised that we needed to avoid merge conflicts so we now
> require that all files are locked before edits are made and we set a
> property on all files that forces the lock to be acquired prior to
> any edits. 

Obviously no one likes to get merge conflicts, but why is that such a
big deal?  Are you dealing exclusively with unmergable binary files or
something?  Requiring locks on all files is not a solution that anyone
that uses Subversion would recommend -- ever.  Only exception being
binary files.

> It does quite often
> attempt to acquire multiple locks on the same file. The subsequent
> attempts fail with an error in the console but they can be safely
> ignored, so it's a relatively minor nuisance only. The worst I?ve
> ever encountered was a sequence of about 20 lock dialogs, after a
> process move operation as I recall, that had me thinking I was stuck
> in a loop but it eventually completed successfully. I think with an
> enhancement to the hook script we could probably resolve this.

I have never heard of this happening.  You are saying the lock dialog
is coming up 20 times for one file?  Do you have a reproducible
scenario?  If so report it to users@xxxxxxxxxxxxxxxxxxxxx  In general,
it is Eclipse that calls the method that causes that dialog to come up.
I cannot imagine why it would happen so often though.

> The only deficiency that I've noticed is that unlike TortoiseSVN it
> doesn't recursively search for files that have not yet been added to
> the repository so I would need to know the files to add. 

Commit will show unversioned files in the dialog and add them as part
of the commit.

> The only identifiable problem is if I attempt two
> operations that affect the filename without a commit in between.

This is a limitation that exists within Subversion itself.  The
Subclipse team has actually fixed/enhanced this in Subversion and it
will be part of the 1.5 release (no date at the moment).

Mark