查看: 9165|回复: 6
FASTBOOT&RESCUE MODE
Please Computer Usb Cable to
Your Computer and Open Hisuite
More lnfirmation:
http://zh./
Emotiondownload.php?mod=restore
用一键刷入recovery工具总是遇到停留在这个界面，刷不进，我都无语了
很久以前我就已经解锁了，而且顺利刷机了很多次，前几天因为刷出问题了，觉得还是官方的好，就刷回官方recovery，强刷回了最新的emui2.3，没想到 不能root，于是又想刷第三方recovery，便于以后刷有root的包。卡死在上面的fastboot的问题上面
请问论坛大神，我这样是为什么啊？有什么办法吗？深夜跪谢了。。。
来自手机版
回退旧版本官方包到138再更新rec
来自手机版
没有显示unlock,建议重新运行解锁步骤
工作第一 发表于
回退旧版本官方包到138再更新rec
您好！非常感谢！~另外我还想请教您一个问题，希望得到您的帮助——
第一次刷机就把串号弄丢了，后来没办法用移动叔叔工具箱，每次刷机完之后都要重新恢复。
这次换成官方recovery强刷，居然还是没有串号，偏偏emui2.3最新版又找不到root办法，移动叔叔工具箱不能用了
求教论坛大神：怎么永久恢复串号？或者在现在不root的情况下恢复过来也行啊谢谢大神！~
请问你的解决了莫？我最近也遇到了这个问题
工作第一 发表于
回退旧版本官方包到138再更新rec
你好工大，我就是这个问题
请问如何操作，我的电脑是WIN7 64 位
怎么回退旧版本官方138？
您好，我也遇到此问题
而且情况和你几乎一样
请问如何解决，怎么回退旧版本官方138？
移动叔叔. 版权所有，专业的网络售后平台 (
商务合作||||Read the official Subversion
documentation !
Apache Subversion 1.6 Release Notes
What's New in Apache Subversion 1.6
Apache Subversion 1.6 is a superset of all previous Subversion
releases, and is as of the time of its release considered the current
"best" release.
Any feature or bugfix in 1.0.x through 1.5.x is also
in 1.6, but 1.6 contains features and bugfixes not present in any
earlier release.
The new features will eventually be documented in a
1.6 version of the free Subversion book
This page describes only major changes.
For a complete list of
changes, see the 1.6 section of the CHANGES
Compatibility Concerns
Older clients and servers interoperate transparently with 1.6
servers and clients.
However, some of the new 1.6 features may not be
available unless both client and server are the latest version.
also cases where a new feature will work but will run less efficiently if
the client is new and the server old.
There is no need to dump and reload your
repositories.
Subversion 1.6 can read repositories created by earlier
To upgrade an existing installation, just install the
newest libraries and binaries on top of the older ones.
Subversion 1.6 maintains API/ABI compatibility with earlier
releases, by only adding new functions, never removing old ones.
program written to the 1.0, 1.1, 1.2, 1.3, 1.4 or 1.5 API can both compile
and run using 1.6 libraries.
However, a program written for 1.6
cannot necessarily compile or run against older libraries.
New Feature Compatibility Table
New Feature
Minimum Client1
Minimum Server
Minimum Repository
Using servers older than 1.6 is possible, but some kinds
of conflicts will not be detected.
1Reminder: when using the file://
repository access method, the Subversion program is both the client
and the server.
Working Copy and Repository Filesystem Format Changes
The working copy format has been upgraded.
This means that 1.5 and
older Subversion clients will not be able to work with
working copies produced by Subversion 1.6.
Working copies are upgraded automatically.
Similarly, the repository filesystem formats have changed, meaning
that 1.5 and older versions of Subversion tools that normally access
a repository directly (e.g. svnserve, mod_dav_svn,
svnadmin) won't be able to read a repository created by
Subversion 1.6.
But, repositories are .
Working Copy Upgrades
WARNING: if a Subversion 1.6 client encounters a
pre-1.6 working copy, it will automatically upgrade the
working copy format as soon as it touches it, making it unreadable by
older Subversion clients.
If you are using several versions of
Subversion on your machine, be careful about which version you use in
which working copy, to avoid accidentally upgrading a working copy.
(But note that this "auto upgrade" behavior does not occur
with the , only working
If you accidentally upgrade a 1.5 working copy to 1.6, and wish to
downgrade back to 1.5, use the change-svn-wc-format.py script.
See this FAQ entry for details, and run the script with the
--help option for usage instructions.
Repository Upgrades
The Subversion 1.6 server works with 1.5 and older repositories,
and it will not upgrade such repositories to 1.6 unless
specifically requested to via the
svnadmin&upgrade command.
This means
that some of the new 1.6 features will not become available simply by
upgrading your server: you will also have to upgrade your
repositories.
(We decided not to auto-upgrade repositories because we
didn't want 1.6 to silently make repositories unusable by
1.5&&&that step should be a conscious decision on the
part of the repository admin.)
Command Line Output Changes
Although we try hard to keep output from the command line programs
compatible between releases, new information sometimes has to be
This can break scripts that rely on the exact format of the
Improved output of svn proplist --verbose
The output of svn proplist --verbose has been
improved, and svn propget now accepts the --verbose
The following example illustrates these changes.
$ svn proplist --verbose build.conf
Properties on 'build.conf':
svn:eol-style
svn:mergeinfo
/trunk/build.conf:1-4800
/branches/a/build.conf:
/branches/b/build.conf:
Changed output of svn status
The output of svn status contains the additional seventh
column which informs whether the item is the victim of a tree conflict.
An additional line with more detailed description of a tree conflict is
displayed after each item remaining in tree conflict.
$ svn status
Makefile.in
C src/error.c
local add, incoming add upon update
C src/path.c
local edit, incoming delete upon update
C src/properties.c
local delete, incoming edit upon merge
C src/time.c
Conflict summary printed by svn update and
svn update and svn merge now print
a summary of conflicts upon completion.
$ svn update --accept=postpone
Updated to revision 3.
Summary of conflicts:
Text conflicts: 1
Property conflicts: 1
Tree conflicts: 1
Minor problems with the conflict summary are described in
Hook Changes
Changed handling of output of pre-lock hook
The output of pre-lock hook was previously discarded, but now
it is used to specify the names of lock tokens.
New Features
Improved handling of authentication data (client)
This section is currently incomplete, please
help write it!
Prompting before storing passwords in plaintext form
Subversion prompts before storing passwords in plaintext form.
$ svn checkout /repository/trunk repository_trunk
Authentication realm: && Example
Password for 'user':
-----------------------------------------------------------------------
ATTENTION!
Your password for authentication realm:
&& Example
can only be stored to disk unencrypted!
You are advised to configure
your system so that Subversion can store passwords encrypted, if
See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/home/user/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)?
Support for storing passwords in KWallet and GNOME Keyring (Unix-like systems)
Passwords can be stored in KWallet (KDE 4) and GNOME Keyring.
Support for storing SSL client certificate passphrases
SSL client certificate passphrases can be stored in KWallet, GNOME
Keyring, Mac OS Keychain, a Windows CryptoAPI encrypted form or in plaintext form.
Repository root relative URLs (client)
This section is currently incomplete, please
help write it!
for more information.
$ svn SUBCOMMAND ^/
$ svn SUBCOMMAND ^/PATH
Improvements to svn:externals
Subversion 1.6 adds a couple of new features for users of
svn:externals.
The include:
Support for files in svn:externals
If the URL in a svn:externals description refers to a file,
it will be added into the working copy as a versioned item.
There are a few differences between directory and file
externals.
The path to the file external must be in a working copy that is
already checked out.
While directory externals can place the
external directory at any depth and it will create any
intermediate directories, file externals must be placed into a
working copy that is already checked out.
The file external's URL must be in the same repository as the URL
that the file external w inter-repository
file externals are not supported.
While commits do not descend into a directory external, a commit
in a directory containing a file external will commit any
modifications to the file external.
The differences between a normal versioned file and a file
File externals cannot the
svn:externals property must however,
file externals can be copied.
Other facts.
A file external shows up as a X in the switched status
Support usual shell quoting rules in externals definitions
(, client)
Need to document possible incompatibilities (see
Further reading
See The svn:externals section of the Subversion Book.
Detection of tree conflicts (client)
Subversion 1.6 recognizes a new kind of conflict, known as a
&tree conflict&. Such conflicts manifest at the level
of directory structure, rather than file content.
Situations now flagged as conflicts include deletions of locally
modified files, and incoming edits to locally deleted files. Files
and directories which are victims of a tree conflict cannot be
committed before the conflict is marked resolved.
Note that Subversion is still treating renames as a &copy+delete&
operation, so file renames causing tree conflicts can only be detected
in terms of file additions and deletions. Because of this, false positives
during tree conflict detection are possible.
To facilitate tree conflict detection, attempting to commit the
deletion of a file which has already been deleted in the HEAD revision
now causes an error. In Subversion 1.5, this was treated as a no-op,
potentially resulting in &empty& revisions which contained
no changes.
Further reading
See the tree conflicts section of the Subversion Book.
Filesystem Storage Improvements
Subversion 1.6 contains several improvements to both the Berkeley DB and FSFS
These are designed to improve storage space, and can result in
drastically smaller repositories.
These changes include:
Sharing multiple common representations
When using many branches and merging between them often, it is common to
have files with similar lines of history which contain the exact same content.
In the past, Subversion has stored these files as deltas against previous
versions of the file.
Subversion 1.6 will now use existing representations in
the filesystem for duplicate storage.
Depending on the size of the repository,
and the degree of branching and merging, this can cause an up to 20% space
reduction for Berkeley DB repositories and a 15% reduction for FSFS
repositories.
FSFS repositories: Packing completed shards (server)
Subversion 1.5 introduced the ability for FSFS repositories to be
multiple directories for revision and revprop files.
Subversion 1.6 takes
the sharding concept further, and allows full shard directories to be
packed into a single file.
By reducing internal fragmentation in
the filesystem, packed FSFS repositories have significant space savings
over their unpacked counterparts, especially repositories which contain
many small commits.
Using a one-file-per-shard approach also allows
Subversion to reduce disk I/O and better exploit operating system caches.
To pack a repository, run svnadmin pack on the repository.
Once a repository has been packed, there is no migration path back to an
unpacked state, and it can only be read by Subversion 1.6 or greater
FSFS repositories: Support for Memcached (server)
cache data of FSFS repositories.
Additional build-time dependencies: APR-Util &1.3 || ( APR-Util &
1.3 && APR_Memcache )
BDB repositories: Forward deltas (server)
Newly created BDB repositories now use forward deltas instead of reverse
deltas. svnadmin upgrade can be used to make older repositories
use forward deltas for new revisions. If you want to achieve the most
optimized state of an older repository, you still need to perform dump and
load of the repository.
Ctypes Python Bindings
Subversion 1.6 introduces a new python binding for the Subversion API. The
new binding makes use of the ctypes library to present the standard API along
with a selection of Python classes to give an object-oriented interface to
standard Subversion constructs.
These bindings have several advantages over
the traditional SWIG-based bindings:
Generated automatically
Straightforward, and don't have any special "transformation" rules
Pure python and cross-platform
Both forward and backward compatible as long as the functions used in the programs
have compatible definitions
High level classes make it easy to access common subversion
functionality in a pythonic way
Building the ctypes bindings produces two ways to access Subversion from
python. The first interface is a direct python port of the standard API.
Ctypes provides some basic type conversions and allows the calling of
Subversion functions just like in C code. The new bindings also introduce a
set of python classes to enable higher-level access to Subversion features.
These classes take full advantage of python features and hide as much of the
C implementation as possible to make Subversion easier to use for python
programmers not familiar with the C API.
Enhancements and Bugfixes
Improved interactive conflict resolution (client)
Interactive conflict resolution supports new display-conflict,
mine-conflict and theirs-conflict options.
Here's an example using the command-line client:
Makefile.in
Conflict discovered in 'configure.ac'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: s
- change merged file in an editor
(df) diff-full
- show all changes made to merged file
- accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict
- accept my version for all conflicts (same)
(tc) theirs-conflict
- accept their version for all conflicts (same)
(mf) mine-full
- accept my version of entire file (even non-conflicts)
(tf) theirs-full
- accept their version of entire file (same)
- mark the conflict to be resolved later
- launch external tool to resolve conflict
- show this list
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options: mc
configure.ac
Updated to revision 36666.
Sparse directory exclusion
In Subversion 1.6, the --set-depth parameter to svn
update has grown a new value&exclude. This value tells
Subversion to exclude the target from the working copy, immediately and until
further notice. Prior to Subversion 1.6, if a directory could not easily be
removed from a working copy.
If it was deleted without the help of Subversion,
it would return on the next svn update.
If it was deleted with
svn delete, the directory remained as a local modification
forever. (Unless, of course, it was accidentally committed.)
The new exclusion
mechanism in Subversion 1.6 fixes both these problems.
Note that if you exclude a versioned directory that has some unversioned
files in it, or some files with local modifications, Subversion handles this
situation gracefully. All the files that aren't safe to delete, Subversion
leaves around, and of course leaves any intermediate directories required to
reach those files, too.
Further reading
for more examples and information.
Logging support for svnserve (server)
svnserve now accepts the --log-file option which
allows to specify the file used for logging.
New public 'historical' HTTP URI syntax for mod_dav_svn (server)
mod_dav_svn now supports a new public URI syntax for
examining older versions of files or directories.
The intent here is
to allow users to examine history without the use of an svn client,
and to make it easier for 3rd-party tools (e.g. code-review services)
to work directly against repositories without using svn libraries.
http://host/repos/path?[p=PEG][&r=REV]
The new syntax works similarly to the way URIs work with the svn
commandline client.
Simply requesting http://host/repos/path
fetches "path" in the HEAD revision.
Adding a "p" query argument
specifies a different peg revision instead, so that:
http://host/repos/path?p=38
...is similar to specifying "path@38" on the commandline.
"r" query argument is like specifying "-r" on the commandline,
causing the repository to follow history backwards from the peg
revision to the older operative revision:
http://host/repos/path?p=38&r=20
As with the commandline, the peg revision defaults to HEAD if
unspecified, and the operative revision defaults to the peg
The online Subversion Book has
in great detail.
Command-line client improvements (client)
There are far too many enhancements and new options to the
command-line client to list them all here.
Aside from all the ones
mentioned already in these release notes, below are a few more that we
consider important, but please see the 1.6.0 section in the CHANGES file
for a complete list.
log can take multiple revisions
The svn log command can now take multiple revision arguments
in one invocation.
Both the -c and -r arguments are supported.
$ svn log -r36169 -r36171 http://svn.collab.net/repos/svn/
------------------------------------------------------------------------
r36169 | sussman |
14:46:44 -0800 (Thu, 26 Feb 2009) | 1 line
...log message omitted...
------------------------------------------------------------------------
r36171 | joeswatosh |
22:05:28 -0800 (Thu, 26 Feb 2009) | 20 lines
...log message omitted...
$ svn log -c http://svn.collab.net/repos/svn/
------------------------------------------------------------------------
r36169 | sussman |
14:46:44 -0800 (Thu, 26 Feb 2009) | 1 line
...log message omitted...
------------------------------------------------------------------------
r36171 | joeswatosh |
22:05:28 -0800 (Thu, 26 Feb 2009) | 20 lines
...log message omitted...
--trust-server-cert option
Option added to svn and svnsync, so that
non-interactive operations can work with self-signed certificates not
backed by a known trust authority.
with this option:
$ svn log -r36364 https://svn.collab.net/repos/svn/trunk --trust-server-cert --non-interactive
------------------------------------------------------------------------
r36364 | stylesen |
13:11:20 +0530 (Fri, 06 Mar 2009) | 3 lines
...log message omitted...
------------------------------------------------------------------------
without this option:
$ svn log -r36364 https://svn.collab.net/repos/svn/trunk
Error validating server certificate for 'https://svn.collab.net':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: svn.collab.net
- Valid: from Sep 24 22:01:07 2007 GMT until Sep 23 22:01:07 2011 GMT
- Issuer: sv, CollabNet, Brisbane, California, US
- Fingerprint:
AA:5B:74:B1:E2:7F:38:B3:2B:C2:B1:60:6E:01:BB:F5:7C:37:98:46
(R)eject, accept (t)emporarily or accept (p)ermanently? t
------------------------------------------------------------------------
r36364 | stylesen |
13:11:20 +0530 (Fri, 06 Mar 2009) | 3 lines
...log message omitted...
------------------------------------------------------------------------
API changes, improvements and language bindings
(client and server)
The pre-lock hook can now specify the lock-token string
via the hook' see r32778 for details.
Note that when the hook uses this feature,
it must take responsibility for ensuring that lock tokens are unique
across the repository.
There are too many new and revised APIs in Subversion 1.6.0 to list
them all here.
See the Subversion API
Documentation page for general API information.
If you develop a
3rd-party client application that uses Subversion APIs, you should
probably look at the header files for the interfaces you use and see
what's changed.
One general change is that most APIs that formerly took a
recurse parameter have been upgraded to accept a
depth parameter instead, to enable the new sparse checkouts feature.
Language bindings have mostly been updated for the new APIs, though
some may lag more than others.
Bug fixes (client and server)
A great many bugs have been fixed.
See the 1.6.0 section in the CHANGES file
for details.
Known issues in the release
KWallet GCC 4.7 Compile Error
Building Subversion 1.6.20, or earlier, with GCC 4.7 will fail to
compile when configured to include KDE wallet support. This can be
fixed by configuring without KDE wallet support, or by building with
an older GCC, or by patching
trunk. A fix is likely to be included in any future 1.6.x release.
Testsuite fails
There are known testsuite fails that occur intermittently:
log_tests.py 30. This can be fixed by patching
diff_tests.py 32 as the testsuite does not account for the
random output order of 'svn diff'.
Ruby swig test_dump as the testsuite does not account for the
random property order in dump files.
Subversion 1.4.x series no longer supported
The Subversion 1.4.x line is no longer supported.
This doesn't
mean that your 1.4 in if it works well and is all
you need, that's fine.
"No longer supported" just means we've stopped
accepting bug reports against 1.4.x versions, and will not make any
more 1.4.x bugfix releases.
New Dependency: SQLite
We now require
to build both
the server and client.
We recommend 3.6.13 or greater, but work with
anything better than 3.4.0.
Subversion will attempt to use an SQLite
present in the root of the distribution tarball, otherwise, Subversion will
search for SQLite in the usual places on the system.
You may also pass
--with-sqlite to configure to specify the location
of the SQLite library or amalgamation you wish to use.