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...
And just IMHO: If you've done a 3000+ file project without version
control so far, this should be the least of your problems! :-D
Also, if you really must, you can still use something similar to your
old approach, right? Use Beyond Compare or whatever to "mark" your
changes as belonging to feature A or bug B before you commit. That's not
so nice from a Subversion perspective, but at least you'd keep your
"existing functionality" (i.e. a text editor?!) in those cases. I think
the overhead for this is, was and will be significant, so it's much
better to finish A before starting B if you really want to "track" it
separately.
Holger
>
> ----------------------------------------------------------- start paste
>
> The problems we are solving
> ---------------------------------------
> Subversion users typically edit sets of files in their working copy.
> If a working copy contains a set of edited files which represents a
> single logical change, then commands like 'svn diff', 'svn status',
> 'svn revert' and 'svn commit' automatically discover the edited files
> and act on them.
>
> A common problem, however, is that users often work on more than one
> set of logical changes at a time. The user is required to remember
> which edited file belongs to which set, and carefully run 'diff',
> 'revert', or 'commit' commands only on lists of files which belong
> together.
>
> One workaround for this problem is to checkout multiple working
> copies, and have one task per working copy. Of course, this uses a
> lot of disk space, and it's sometimes inconvenient to move around
> between working copies.
>
> The simple solution we're proposing here is to teach the svn client
> (and working copy) do some simple management of local, human-named
> sets of files, known as 'changesets'. The goal is to allow users to
> create, view, and manipulate sets of files in a working copy by
> referring to them by name.
>
> ----------------------------------------------------------- stop paste
>
>
> On 8/24/06, Karl Fogel <kfogel@google.com> wrote:
>
>> "John Doisneau" <jdoisneau@gmail.com> writes:
>> > Hmmm, that's what I figured out then. It's quite long, but I guess
>> > that it can give some time to plan the feature before entering the
>> > dark codewoods ;)
>> >
>> > Well, I guess we can close this conversation then. Like I said, it
>> > helped a lot.
>>
>> The upcoming "changelist" feature may help:
>>
>> http://svn.collab.net/repos/svn/trunk/notes/changelist-design.txt
>>
>> -Karl
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 25 17:15:07 2006