~bzr-pqm/bzr/bzr.dev

I think Ruby's point is right: we need to think about how a tool

*feels* as you're using it.

Making regular commits gives a nice rhythm to to working; in some

ways it's nicer to just commit single files with C-x v v than to build

complex changesets.  (See gmane.c.v-c.arch.devel post 19 Nov, Tom

Lord.)

* Would like to generate an activity report, to e.g. mail to your boss

  or post to your blog.  "What did I change today, across all these

  specified branches?"

* It is possibly nice that tla by default forbids you from committing

  if emacs autosave or lock files exist -- I find it confusing to

  commit somethin other than what is shown in the editor window

  because there are unsaved changes. 

  However, grumbling about unknown files is annoying, and requiring

  people to edit regexps in the id-tagging-method file to fix it is

  totally unreasonable.

  Perhaps there should be a preference to abort on unknown files, or

  perhaps it should be possible to specify forbidden files.

  Perhaps this is related to a mechanism to detect conflicted files:

  should refuse to commit if there are any .rej files lying around.

   *Those who lose history are doomed to recreate it.*

         -- broked (on #gnu.arch.users)

   *A universal convention supplies all of maintainability, clarity, consistency, and a foundation for good programming habits too. What it doesn't do is insist that you follow it against your will. That's Python!*

    -- Tim Peters on comp.lang.python, 2001-06-16

    (Bazaar provides mechanism and convention, but it is up to you

    whether you wish to follow or enforce that convention.)

----

jblack asks for 

   A way to subtract merges, so that you can see the work you've done

   to a branch since conception.

----

:: 

  <mpool> now that is a neat idea: advertise branches over zeroconf

  <mpool> should make lca fun :-)

----

http://thedailywtf.com/ShowPost.aspx?PostID=24281

  Source control is necessary and useful, but in a team of one (or even two) people the setup overhead isn't always worth it--especially if you're going to join source control in a month, and you don't want to have to migrate everything out of your existing (in my case, skunkworks) system before you can use it.

  At least that was my experience--I putzed with CVS a bit and knew other source control systems pretty well, but in the day-to-day it wasn't worth the bother (granted, I was a bit offended at having to wait to use the mainline source control, but that's another matter).

I think Bazaar-NG will have such low setup overhead (just ``init``,

``add``) that it can be easily used for even tiny projects.  The

ability to merge previously-unrelated trees means they can fold their

project in later.

----

From tridge:

* cope without $EMAIL better

* notes at start of .bzr.log:

  * you can delete this

  * or include it in bug reports

* should you be able to remove things from the default ignore list?

* headers at start of diff, giving some comments, perhaps dates

  * is diff against /dev/null really OK?  I think so.

* separate remove/delete commands?  

* detect files which were removed and now in 'missing' state

* should we actually compare files for 'status', or check mtime and

  size; reading every file in the samba source tree can take a long

  time.

  without this, doing a status on a large tree can be very slow.  but

  relying on mtime/size is a bit dangerous.

  people really do work on trees which take a large chunk of memory

  and which will not stay in memory

* status up-to-date files: not 'U', and don't list without --all

* if status does compare file text, then it should be quick when

  checking just a single file

* wrapper for svn that every time run logs

  - command

  - all inputs

  - time it took

  - sufficient to replay everything

  - record all files

* status crashes if a file is missing

* option for -p1 level on diff, etc.  perhaps

* commit without message should start $EDITOR

* don't duplicate all files on commit

* start importing tridge-junkcode

* perhaps need xdelta storage sooner rather than later, to handle very

  large file

----

The first operation most people do with a new version-control system

is *not* making their own project, but rather getting a checkout of an

existing project, building it, and possibly submitting a patch.  So

those operations should be *extremely* easy.

----

* Way to check that a branch is fully merged, and no longer needed:

  should mean all its changes have been integrated upstream, no

  uncommitted changes or rejects or unknown files.

* Filter revisions by containing a particular word (as for log).

  Perhaps have key-value fields that might be used for

  e.g. line-of-development or bug nr?

* List difference in the revisions on one branch vs another.

* Perhaps use a partially-readable but still hopefully unique ID for

  revisions/inventories?

* Preview what will happen in a merge before it is applied

* When a changeset deletes a file, should have the option to just make

  it unknown/ignored.

  Perhaps this is best handled by an interactive merge.  If the file

  is unchanged locally and deleted remotely, it will by default be

  deleted (but the user has the option to reject the delete, or to

  make it just unversioned, or to save a copy.)  If it is modified

  locall then the user still needs to choose between those options but

  there is no default (or perhaps the default is to reject the delete.)

* interactive commit, prompting whether each hunk should be sent (as

  for darcs)

* Write up something about detection of unmodified files

* Preview a merge so as to get some idea what will happen:

  * What revisions will be merged (log entries, etc)

  * What files will be affected?

  * Are those simple updates, or have they been updated locally as

    well.

  * Any renames or metadata clashes?

  * Show diffs or conflict markers.

  * Do the merge, but write into a second directory.

* "Show me all changesets that touch this file"

  Can be done by walking back through all revisions, and filtering out

  those where the file-id either gets a new name or a new text.  

* Way to commit backdated revisions or pretend to be something by

  someone else, for the benefit of import tools; in general allow

  everything taken from the current environment to be overridden.

* Cope well when trying to checkout or update over a flaky

  connection.  Passive HTTP possibly helps with this: we can fetch all

  the file texts first, then the inventory, and can even retry

  interrupted connections.

* Use readline for reading log messages, and store a history of

  previous commit messages!

----

20050218090900.GA2071@opteron.random

    Subject:      Re: [darcs-users] Re: [BK] upgrade will be needed

    From:         Andrea Arcangeli <andrea@suse.de>

    Newsgroups:   gmane.linux.kernel

    Date:         Fri, 18 Feb 2005 10:09:00 +0100

    On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote:

    > small to medium sized ones). Last I checked, Arch was still too slow in 

    > some areas, though that might have changed in recent months. Also, many 

    IMHO someone needs to rewrite ARCH using the RCS or SCCS format for the

    backend and a single file for the changesets and with sane parameters

    conventions miming SVN. The internal algorithms of arch seems the most

    advanced possible. It's just the interface and the fs backend that's so

    bad and doesn't compress in the backups either.  SVN bsddb doesn't

    compress either by default, but at least the new fsfs compresses pretty

    well, not as good as CVS, but not as badly as bsddb and arch either.

    I may be completely wrong, so take the above just as a humble

    suggestion.

    darcs scares me a bit because it's in haskell, I don't believe very much

    in functional languages for compute intensive stuff, ram utilization

    skyrockets sometime (I wouldn't like to need >1G of ram to manage the

    tree). Other languages like python or perl are much slower than C/C++

    too but at least ram utilization can be normally dominated to sane

    levels with them and they can be greatly optimized easily with C/C++

    extensions of the performance critical parts.