~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!

* Warn when adding huge files(?) - more than say 10MB?  On the other
  hand, why not just cope?

* Perhaps allow people to specify a revision-id, much as people have
  unique but human-assigned names for patches at the moment?

----

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.


-----


* Fix up diffs for files without a trailing newline

-----

* Directly import diffs!  It seems a bit redundant to need to rescan
  the directory to work out what files diff added/deleted/changed when
  all the information is there in the diff in the first place.
  Getting the exact behaviour for added/deleted subdirectories etc
  might be hard.

  At the very least we could run diffstat over the diff, or perhaps
  read the status output from patch.  Just knowing which files might
  be modified would be enough to guide the add and commit.
  
  Given this we might be able to import patches at 1/second or better.


----

When sending patches by email (optionall) send each one as a separate
mail, with a sequence number [%03d/%03d] at the start of the Subject.
See mail from linus 2005-04-07.

http://linux.yyz.us/patch-format.html

http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

----

dwmw2 (2005-04-07) 

reorder patches by cherry-picking them from a main development tree
before sending them on.