/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/transports.txt

  • Committer: Jelmer Vernooij
  • Date: 2017-07-23 22:06:41 UTC
  • mfrom: (6738 trunk)
  • mto: This revision was merged to the branch mainline in revision 6739.
  • Revision ID: jelmer@jelmer.uk-20170723220641-69eczax9bmv8d6kk
Merge trunk, address review comments.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/transports.txt
1
1
####################################
2
 
Developer guide to breezy transports
 
2
Developer guide to bzrlib transports
3
3
####################################
4
4
 
5
 
This guide describes the `Transport` classes that Breezy uses for most
 
5
This guide describes the `Transport` classes that Bazaar uses for most
6
6
local and remote file access.  (Working tree files are the major
7
7
exception (`bug 606249 <https://bugs.launchpad.net/bzr/+bug/606249>`).
8
8
 
23
23
 
24
24
    self.requireFeature(tests.SymlinkFeature)
25
25
 
26
 
Breezy versions symlinks as objects in their own right, whose content is
27
 
the path they point to.  Breezy doesn't care whether a versioned
 
26
Bazaar versions symlinks as objects in their own right, whose content is
 
27
the path they point to.  bzr doesn't care whether a versioned
28
28
symlink is absolute or relative; or whether it points inside or outside
29
29
the working tree; or whether its referent exists or not.  In Unix the
30
 
target of a symlink is a byte string; Breezy treats this as a Unicode string
 
30
target of a symlink is a byte string; bzr treats this as a Unicode string
31
31
in the filesystem encoding (`osutils._fs_enc`).
32
32
 
33
 
So when we say ``brz add symlink``, this should always add the symlink to
 
33
So when we say ``bzr add symlink``, this should always add the symlink to
34
34
its containing working tree, and never dereference the symlink.
35
35
 
36
 
However, ``brz add symlink/file`` shouldn't add ``file`` as a child of
 
36
However, ``bzr add symlink/file`` shouldn't add ``file`` as a child of
37
37
``symlink``.  (Symlinks don't have files underneath them: they may point to
38
38
a directory which contains children, but if the symlink was pointed
39
39
somewhere else those children would be unaffected.)  This could either add
41
41
 
42
42
One interesting case for this is ::
43
43
 
44
 
    brz add ~/dev/bug123/a.c
 
44
    bzr add ~/dev/bug123/a.c
45
45
 
46
46
where ``~/dev`` is actually a symlink to ``/srv/dev/joe/``.  In this case
47
47
clearly the user does want us to follow the symlink to open the tree.
54
54
Useful functions
55
55
----------------
56
56
 
57
 
`breezy.osutils.dereference_path` does the commonly useful operation of
 
57
`bzrlib.osutils.dereference_path` does the commonly useful operation of
58
58
resolving the directory part of a path, but leaving the filename
59
59
untouched.  In other words ::
60
60
 
90
90
 
91
91
On local, SFTP and bzr+ssh transports, we can directly see symlinks as
92
92
symlinks.  Over HTTP (and FTP?) they're expanded by the server and we
93
 
cannot detect them.  This can cause problems when Breezy follows relative
 
93
cannot detect them.  This can cause problems when bzr follows relative
94
94
paths because typically we will join the paths, and we may do this
95
95
inconsistently with how the server, which can see the symlinks, would do.
96
96
 
98
98
Symlinks and ChrootTransports
99
99
-----------------------------
100
100
 
101
 
Breezy has an internal concept of a `ChrootTransport` that locks access into
 
101
bzr has an internal concept of a `ChrootTransport` that locks access into
102
102
a particular directory.  Symlinks should not break out of a chroot jail
103
 
which implies they should be expanded and checked within breezy.
 
103
which implies they should be expanded and checked within bzrlib.
104
104
(At least as long as the transport lets us see the symlink; otherwise it
105
105
may not be possible.) 
106
106