1
2
3
4
5
6
7
8
9
10
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
+
+
+
|
## Status:
* Fossil 2.0 is currently just an idea. No code has been written.
(Update 2015-05-17: Some of the styling changes have been implemented
on trunk for version 1.33 without being overly disruptive of legacy
third-party skins.)
## Core Principles:
* 100% repository compatible. Reuse existing repos (perhaps with "rebuild")
* 100% sync compatible. Push, pull, and clone with version 1.x repos.
|
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
|
example.) This principle does not change from 1.x.
## Command-line Interface:
* "fossil mv" and "fossil rm" actually rename and delete the underlying
files.
## Other Ideas:
* Partial clones - the ability to clone only recent additions, ignoring
older history.
* Checkout from and commit to a remote repository (via HTTP/HTTPS)
without having to clone. (The implementation would likely be to create
a "partial clone" of just the one check-in that is being checked out.)
* "Slices" - the ability to checkout, edit, and commit against
a subdirectory of the complete source tree.
* Advisory locks - The ability to "lock" a file on a central server to
discourage other people from editing that file while you are working
on it. Useful for binary files (ex: images or movies) that cannot be
merged. Locks are advisory only and can be overridden with appropriate
command-line options so that work can continue if (for example)
one team member locks
a bunch file just before leaving on their three-week vacation.
* Rework the VFILE table in the check-out database so that commits to
repositories with a very large number of files (ex: net-bsd) is more
efficient.
* Optionally allow Fossil to read and write the Git object format
(in addition to its [own format](doc/trunk/www/fileformat.wiki))
so that so that Fossil clone/push/commit with standard Git
implementations. A repository must decide at creation time whether it
will be a Git-format repository or a Fossil-format repository and that
can never be changed. Choosing the Git-format necessarily limits the
things that Fossil can do, but with the trade-off of getting to
participate in the pervasive Git community.
## Implementation Strategy:
* Make changes in a long-running branch (named "fossil-2.0"?) until
ready to cut-over, then merge into trunk.
* Keep two versions of Fossil (1.x and 2.0-alpha) both running on
<https://www.fossil-scm.org/> so that people can compare the changes
|
109
110
111
112
113
114
115
116
117
118
|
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
-
+
+
+
+
+
|
------
*On 2015-05-15 05:49:01 UTC andygoth added:*
# Merge update and checkout
The checkout command is very nearly the same as update. The only differences I can think of are that checkout doesn't trigger an autosync, plus it has -keep to change which checkout is selected without actually modifying files. (Also it has -force, but that's to work around a limitation of checkout not present in update.)
The checkout command is very nearly the same as update. The only differences I can think of are that checkout doesn't trigger an autosync, plus it has -keep to change which checkout is selected without actually modifying files. (Also it has -force, but that's to work around a limitation of checkout not present in update.) <i>-- drh replies:
Update merges any changes in the working directory over to the new version.
Checkout does not. Checkout requires that there be no changes in the working
directory, or else that the --force flag be used which overwrites all local
changes.</i>
I actually use "checkout -force -keep" a bunch when synchronizing Fossil with other revision control systems, so this functionality must remain, even if it becomes "update -keep".
|