RE: RE: Re: Commit sets

Ok - you are correct on the 3.0 commit sets - they were just looking
through the history - but now they are able to be defined in 3.1M2 -
from
http://download2.eclipse.org/downloads/drops/S-3.1M2-200409240800/eclips
e-news-M2.html - item 4 (sorry if html is a problem - please let me
know)

<snip>

CVS outgoing commit sets

Outgoing commit sets allow you to organize outgoing changes into logical
groups before they are committed. To enable commit sets, click on the
commit set button in the Synchronize View, then select an outgoing
change and choose Add To > New Commit Set... from the context menu. You
can also appoint a commit set as the default and have all subsequent
outgoing changes added to that set automatically. Commands on the
context menu allow outgoing changes to be moved between commit sets.
When the change set is committed to the CVS repository, the name of the
commit set is used as the CVS commit comment.

</snip>

In essence, we are essentially tagging files that we want to update in
certain fixes or changes. When we commit a set, it will only commit
those files that are in the commit set, and any unfinished work in other
areas will remain unaffected.

This would also be ideal for working offline.

-----Original Message-----
From: Mark Phippard [mailto:MarkP@softlanding.com]
Sent: Thursday, 7 October 2004 9:52 a.m.
To: users@subclipse.tigris.org
Subject: RE: Re: Commit sets

I guess to step back, I would say it like this.

1) Any features you see within Eclipse for the CVS client are specific

to that client. In general, there are no "global team" features in

Eclipse that other providers just inherit. Eclipse has refactored some
of

their CVS code to make it more easy for other team providers to reuse.
So

in some cases, at least in theory it is possible to recreate some of the

CVS features.

2) Subclipse developers are likely to be using Subclipse/Subversion and

not CVS. Although some may use both. Anyway, the point is do not make

the assumption that anyone knows what you are talking about.

Where these points leave us is view this as a feature request and
explain

what you want to be able to do, and ideally express it in Subversion

terms. I remember reading about commit sets in the Eclipse 3.0 release

notes. It looked to me like it was a history feature for making CVS

commits look like they were atomic. Regardless, Subversion is not CVS,

the best thing to do would be to start at the beginning and explain the

feature you need.

Mark

"Stephen Kestle" <Stephen.Kestle@orionhealth.com> wrote on 10/06/2004

04:45:44 PM:

> But I'm in a situation where I'd like to be able to commit different

> files in as parts of different commits. I'd be checking in more, but

> some of the changes are very wide ranging, and I don't want to get
merge

> conflicts when the branches a finally merged (which we're trying to
get

> to).

>

> In 3.1M2, you can tag files to go into different commit sets, and then

> at a later stage, you can commit them, without having to try and

> remember what file was changed in what bug fix etc.

>

> Also, I do understand that I could make cheap copies, and that I'll
have

> to merge anyhow in my working copy, but it's just easier to leave it

> checked out.

>

> -----Original Message-----

> From: Mark Phippard [mailto:MarkP@softlanding.com]

> Sent: Thursday, 7 October 2004 9:34 a.m.

> To: users@subclipse.tigris.org

> Subject: Re: Commit sets

>

> My understanding of commit sets is that they are simply parsing the

> commit

> info in CVS to simulate "atomic commits". This is just a feature that

> is

> inherent to Subversion and Subclipse.

>

>

>

> "Stephen Kestle" <Stephen.Kestle@orionhealth.com> wrote on 10/06/2004

> 04:30:01 PM:

>

> > I just installed eclipse 3.1M2 because I thought "hey, commit sets -

> > that's exactly what I need right now"

> >

> > But alas, it is only for CVS. Is it possible to get into this

> > functionality for svn, and when is that likely to happen?

> >

> > Cheers

> >

>

>

>
________________________________________________________________________

> _____

> Scanned for SoftLanding Systems, Inc. by IBM Email Security Management

> Services powered by MessageLabs.

>
________________________________________________________________________

> _____

>

> ---------------------------------------------------------------------

> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org

> For additional commands, e-mail: users-help@subclipse.tigris.org

>

>

> ---------------------------------------------------------------------

> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org

> For additional commands, e-mail: users-help@subclipse.tigris.org

>

>

>

________________________________________________________________________
_____

> Scanned for SoftLanding Systems, Inc. by IBM Email Security Management

> Services powered by MessageLabs.

>

________________________________________________________________________
_____

________________________________________________________________________
_____

Scanned for SoftLanding Systems, Inc. by IBM Email Security Management
Services powered by MessageLabs.

________________________________________________________________________
_____

---------------------------------------------------------------------

To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org

For additional commands, e-mail: users-help@subclipse.tigris.org