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

Re: Tagging changesets

From: Blair Zajac <blair_at_orcaware.com>
Date: 2006-08-26 19:30:51 CEST

Holger Stratmann wrote:
> John Doisneau wrote:
>> I cannot believe it. I don't know when it will be supported, but it is
>> *exactly* the problem we discussed
> Yes, the problem.
> But not the solution to the problem :-)
>> (I pasted the relevant paragraph below).
> me too:
> * Overlapping changelists
> A number of people ask "but what if two different changes within a
> single file belong to different logical changes?" My reply is:
> either "tough luck" or "don't do that" or "checkout a separate
> working copy". My feeling is that trying to create a UI to
> manipulate individual diff-hunks within a file is a HUGE can of
> worms, probably best suited for a GUI. While I wouldn't rule it
> out as a future *enchancement* to a changelist feature, it's
> certainly not worth the initial effort in the first draft of
> changelist management. Overlapping changelists do occasionally
> happen, but they're rare enough that's it's not worth spending 90%
> of our time on a 10% case -- at least not in the beginning.
> Oh well...
>> Well, until then, the 2 working copy scheme is the way to go...
> And as somebody's already mentioned: Initial checkout is slow, but going
> to a different revision or a different branch is pretty fast...

If you have a working copy already checked out, a faster approach is to use
rsync, cp -r, etc to just copy the entire working copy into a new directory,
just make sure that your copy copies the .svn directory. Then 'svn revert -R'
in the new copy to revert all local changes. This should be faster.


Blair Zajac, Ph.D.
Subversion training, consulting and support
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Aug 26 19:32:17 2006

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

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