Comparison with Git, Mercurial or Darcs?
Daniel Carrera
dcarrera at gmail.com
Wed Nov 4 12:35:10 GMT 2009
On Wed, Nov 4, 2009 at 1:06 PM, Ben Finney <ben+bazaar at benfinney.id.au> wrote:
> Daniel Carrera <dcarrera at gmail.com> writes:
>> When I'm working on a new feature I send a lot of small test patches
>> to the test server until it works. When it works, I obliterate them on
>> the server, unrecord them on my laptop, and re-record them as a nice
>> set of well organized patches.
>
> All of which would be more straightforward done as a parallel line of
> development, allowing the changes to *remain* in history when later
> merged, and not be obliterated. In other words, a branch.
I don't think we are communicating. I don't *want* a history full of
patches with the web equivalent of "printf('Debug: Entered function
foo()\n')". When I'm developing, most of the time I'm entering
debugging information, or very small incremental changes ("let's try
making to text green... no, let's try red..."). I don't want all of
that junk in my history. I want to finish the feature and when it's
done I'll record a set of logical, self-contained patches.
More on this next:
> I just don't see why there's an advantage in throwing away each of those
> changes that was good enough to record in the first place,
See above. Most of those changes are not things that are "good enough
to record". I only record them because I need to push the changes to a
remote server for testing. That's why I said earlier that I could try
using rsync for this. But rsync would not let me make a branch to
develop a different feature in parallel.
> Surely, to the extent that they make sense as independent patches, they
> *can* be developed in parallel? Conversely, if they *can't* be developed
> in parallel, what's the point of having them as three separate patches?
Example: (A) Add a function to read a list of users from the database,
and (B) create a page that displays that list of users. Feature (A)
does not depend on feature (B). I think it's reasonable to first
record (A) and then record (B). But I still have to develop the two
things together.
This is quite normal for me. A MVC web application has a model, a view
and a controller. It is entirely reasonable to want to record a change
to the model separately from the change to the view. This is what I'm
doing most of the time.
Daniel.
--
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.
More information about the bazaar
mailing list