[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Changelists: the next generation

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-10-13 02:06:48 CEST

Jack Repenning <jackrepenning@tigris.org> writes:
> --no-changelist: an option that can be used anywhere a changelist can
> be used, which means "all the modified things that aren't in a
> changelist."  An obvious use: "svn changelist --no-changelist
> newchangelistname" to mark all your currently unchangelisted changes,
> say before working on an interrupt or distraction.  With the new
> flagging of move-among-changelists feature, this gives you some help
> in avoiding overlapping changelists.  I haven't thought through what
> this means for all cangelist-aware commands, there might be some
> surprises there, somewhere.

I thought we never have overlapping changelists, because we reliably
detect that? (IOW, why would the user need help to avoid that
situation -- don't we already give all the necessary help?)

> svn changelist --work-on changelistname (or some such syntax): meaning
> "any modification I make from now on should automatically be added to
> changelistname."  This automatic change collection is quite similar to
> an extremely popular ClearCase feature (which ClearCase officially
> calls "mkbranch," but which you can think of as "automatic, or latent,
> branch creation").  Again, the warning about changing change lists in
> mid stream interacts pleasantly.  This might be easier to do after the
> admin directory is centralized, should that happen.

Last sentence expresses my thoughts too :-).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 13 02:07:02 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.