Changelists Q2

[John Griffin <Jo...@pwgsc.gc.ca>]

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

Re: Changelists Q2

[Josh Pieper <jj...@pobox.com>]

John Griffin wrote:
> 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?

The Subversion development path is for the most part a free for all.
Whoever is interested in implementing a feature does so.  I haven't
seen any developer working on or interested in Perforce style
changelists so it seems unlikely in the near future.

Aside from that, I manage multiple sets of changes all the time by
keeping a separate working copy (WC) for each change that I am
developing.  I find that this approach works very well, at the expense
of some disk space.

-Josh

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

Re: Changelists Q2

[Arnout Standaert <ar...@student.kuleuven.ac.be>]

Ben Collins-Sussman wrote:

> On Fri, 2004-07-16 at 08:44, Garrett Rooney wrote:
> 
> 
>>I don't think anyone is working on such a thing, and honestly I'm not 
>>sure how it would be implemented.
> 
> 
> It might be something that a good svn GUI can do.   I've heard people
> talk about writing this feature into GUIs, in fact.  Nothing's come of
> it yet.

I remember a thread on the TortoiseSVN list discussing changelists, 
like in Perforce. You might want to check out this message:

http://tortoisesvn.tigris.org/servlets/ReadMsg?list=dev&msgNo=3859

There are a bunch of follow-up messages, a bit scattered under 
different titles, that discuss possible approaches to implement this 
in TSVN. I wouldn't know what the current status is, sorry.

Regards,
Wald

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

Re: Changelists Q2

[Ben Collins-Sussman <su...@collab.net>]

On Fri, 2004-07-16 at 08:44, Garrett Rooney wrote:

> I don't think anyone is working on such a thing, and honestly I'm not 
> sure how it would be implemented.

It might be something that a good svn GUI can do.   I've heard people
talk about writing this feature into GUIs, in fact.  Nothing's come of
it yet.



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

Re: Changelists Q2

[Garrett Rooney <ro...@electricjellyfish.net>]

John Griffin wrote:
> 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?

I don't think anyone is working on such a thing, and honestly I'm not 
sure how it would be implemented.

In Perforce the info about the changelists are stored on the server, and 
they're kept in sync as you 'p4 edit' the various things you're 
changing.  In Subversion the server doesn't track that kind of 
information, so it would have to be maintained in the client.

The current working copy design doesn't lend itself to such things, so 
it would have to be implemented at another level.

Implementing it in the standard client would probably not mesh well with 
things like being able to move working copies or being able to take a 
subset of a working copy and use it as a stand alone working copy, so 
I'm skeptical of this ever happening as part of the standard command 
line client.

There's no reason you can't do essentially the same thing yourself 
though.  Just keep a text file containing a list of each file that's 
part of your changeset and use the 'svn commit --targets FILE' 
functionality when you're committing the final change.  If you want a 
nicer front end to that functionality I imagine it could be pretty 
easily scripted.

-garrett

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