> From: Garrett Rooney [mailto:firstname.lastname@example.org]
> 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 has it spot on: in Perforce, the server has knowledge of the
clients, including the 'p4 edit'ed files and the open change lists,
while Subversion's server has no concept of its clients.
In my previous reply to this subject, I mentioned using TSVN as a
client, allowing you to select which files go into a checkin. If you
like using the command like, you could do something like what Garrett
mentions: using the 'commit --targets FILE' construct. The problem that
I've come across with this is remembering which files to check in. Have
a look at this post to easily find all the files you might checkin, and
then be able to select which files to check in through the command line:
Hope this helps.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jul 16 16:19:25 2004