RE: [Subclipse-users] Problem with atomic commits

Mark,

This is still very confusing to me. For any file in Eclipse, Subclipse knows the full repository path (and thus the repository). It seems a very simple matter to simply examine this property when committing multiple files simultaneously, and for each repository identified create a single commit. The current behavior seems counter-intuitive to me, as I have a discrete file list for which all members are selected, and an IDE operation does not act on the set of files, but instead acts on them based on additional factors not visible in the current perspective/view mode.

It is most confusing to me because the behavior of the plug-in (if I am understanding your explanation correctly) is based on how I configure my workspace (projects within vs. projects external). I would strongly recommend that this be re-examined as either a new feature, an enhancement to the existing atomic functionality, or a bug.

In addition, I would like to request that the documentation be updated to reflect both the current preferences interface and this behavior.

Thanks!

Michael Schechter
mschechter_at_national.aaa.com
RESPONSESupport_at_national.aaa.com

-----Original Message-----
From: Mark Phippard [mailto:markphip_at_gmail.com]
Sent: Tuesday, July 22, 2008 5:21 PM
To: users_at_subclipse.tigris.org
Subject: Re: [Subclipse-users] Problem with atomic commits

On Tue, Jul 22, 2008 at 5:08 PM, Schechter, Michael <MSchechter_at_national.aaa.com> wrote:

> All projects are under a common root directory under my trunk. All
> projects exist at various levels within that structure - we have two top-level parents, and one has additional directory structure while the other does not (all its projects are at the same level).

The structure inside the repository actually does not matter, they just have to all come from the same repository. What does matter is the structure on your local disk. That is what I meant. If you do your checkouts using Subclipse, and checked out all projects directly into your workspace folder, you would be all set. If your local working copy mirrors that repos structure you gave however, then the commits will be grouped by each parent. We could potentially optimize this by crawling back beyond the parent, but right now picture a Map where the key is the parent folder and repository UUID.

> In case it matters, I was using Team Synchronizing in 'flat' mode
> (just files displayed). Could how I have defined the repository in the Eclipse repository explorer have had an effect?

None of that would matter. Once it is in the commit process, it does not know about how you have your UI configured.

--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org