Changelists Q2

Okay,

Let me ask two other questions then. Are Perforce style changelists on the subversion development path? I took a look at the Web site and did not see any mention of changelists. Are Perforce style changelists considered a best practice? If they are considered a "bad" way of doing things what is the best practice for simultaneously managing multiple sets of changes?

John

-----Original Message-----
From: Jay Glanville [mailto:jay.glanville@naturalconvergence.com]
Sent: Thursday, July 15, 2004 10:26 PM
To: John Griffin; users@subversion.tigris.org
Subject: RE: Changelists

> Hi All,
>
> I am new to the list and I am new to svn. I did some
> searching in the archives but could not find the answer I was
> looking for. I am a former Perforce user. One of the features
> I liked in Perforce was the ability to manage multiple
> changelists as a single user. For example, if I was working
> on multiple changes I could manage each set of related files
> under a different changelist and commit the changes at
> different times. My question is, does svn provide this
> functionality? If it does how do I access it? If it does not
> how is this scenario handled using svn?
>
> John

Short answer, no. Long answer ...

My manager likes to refer to the changelist difference between Perforce
and Subversion as explicit changelists vs. implicit changelists.

As you say, in Perforce you can create multiple change lists. Then, you
can associate the changes to a set of files to any one of a number of
separate change lists, either before, during or after you've modified
those files. Basically, you can tell Perforce that 'this' file's
changes are to go to 'that' change list.

However, Subversion really doesn't have change lists: they only have
checkins that can contain multiple files. If you need to think of
things using change lists, think of it this way: in Subversion, you do
not create change lists explicitly, you create them implicitly.
Basically, a change list gets created for you whenever you perform a
check in. You can think of it like this: svn ci == create change list,
add stated files to change list, close change list, check change list
in. There is only ever one change list open at a time, and that is only
open during the check in.

Therefore, to look at your scenario, you could do what someone else has
suggested: multiple working copies (or branches), one per set of
changes. However, this can be a hassle if your working copy gets rather
large.

Another way to do what you want is to use an interface (probably
TortoiseSVN). Basically, with TSVN, when you check in a directory, TSVN
then shows you a list of modified files. Just before you press the
'submit' button, you can remove entries from this list. Basically, this
allows you to work on multiple sets of changes, then when you check in,
you select the files for a single change list.

I have to admit, Perforce's ability to associate modifications to any
one of a number of open change sets is very useful.

Hope this helps you.

JDG

--
Jay Glanville
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org