← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/svk.txt

  • Committer: Robert Collins
  • Date: 2005-10-29 23:48:45 UTC
  • Revision ID: robertc@robertcollins.net-20051029234845-7ae4e7d118bdd3ed
Implement a 'bzr push' command, with saved locations; update diff to return 1.

    * 'bzr diff' now returns 1 when there are changes in the working 
      tree.

    * 'bzr push' now exists and can push changes to a remote location. 
      This uses the transport infrastructure, and can store the remote
      location in the ~/.bazaar/branches.conf configuration file.

    * WorkingTree.pull has been split across Branch and WorkingTree,
      to allow Branch only pulls.

    * commands.display_command now returns the result of the decorated 
      function.

    * LocationConfig now has a set_user_option(key, value) call to save
      a setting in its matching location section (a new one is created
      if needed).

    * Branch has two new methods, get_push_location and set_push_location
      to respectively, get and set the push location.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/svk.txt
6
6
satisfy people who need disconnected operation, and so to allow
7
7
projects to feel safe about switching to Subversion.
8
8
 
9
 
On the other hand it may be a bit flaky in implementation; being
10
 
written in Perl on top of Svn bindings may not inspire confidence;
11
 
relatively little documentation.
 
9
On the other hand it may be a bit flaky in implementation -- when I
 
10
tried it (dec 04), it crashed in confusing ways several times.  And
 
11
certainly Subversion's reputation for reliability is mixed -- some
 
12
people think it's very solid, but I've seen many db crashes at HP.
 
13
 
 
14
Being written in Perl on top of Svn bindings may not inspire
 
15
confidence.  robertc says he's worked with the libsvn bindings and
 
16
they're a mess.  Relatively little documentation.  In general a
 
17
feeling of a very tall stack.
 
18
 
 
19
There is some fluff about defining multiple repositories, which seems
 
20
like an argument for history-in-branch.
 
21
 
 
22
Keeps track of merge arrows to do smart merges.
 
23
 
 
24
They follow Perforce in not having any control files in the tree --
 
25
nice in some ways but you must use the right tool to move or delete a
 
26
working area.  (In fact the whole thing seems to be inspired a bit by
 
27
Perforce?)  I think keeping just one dotfile at the top level may be a
 
28
fair compromise.
 
29
 
 
30
 
 
31
 
 
32
(If this is unfair or inaccurate mail me dammit.)
 
 
b'\\ No newline at end of file'