forked from collective/git-svn-helpers
-
Notifications
You must be signed in to change notification settings - Fork 0
/
HISTORY.txt
127 lines (87 loc) · 3.84 KB
/
HISTORY.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
1.0 - Unreleased
----------------
* No changed yet.
0.9 - 2012-03-11
----------------
* The cannonical repository is now in https://github.com/collective.
[rossp]
* Fix the handling when switching to a svn branch that git already has
a local branch for.
[rossp]
0.8 - 2010-03-10
----------------
* Make the init command follow along if the svn repository has been switched
to another branch. Thanks to Calvin Hendryx-Parker for reporting the issue.
[tomster]
0.7 - 2010-03-07
----------------
* Use full copies instead of symlinks to create working copies. This avoids
the issue of having the git and svn repository out of sync when working
with multiple copies of the same repository and greatly reduces the risk of
conflicts.
This also means, that the fetch command now only operates on the cache
without modifying the working copy (making it safe to run via crontab,
for example)
Running gitify against an old-style working copy will produce an error.
Simply deleting the symlink and re-running gitify remedies that, however.
Another effect, is that the init command is now only needed once for each
working copy (it is no longer necessary to re-run the command after
switching between different working copies of the same repository).
gitify therefore no longer defaults to the init command (just as neither
git nor svn do anything w/o supplying an explicit action). Also, it has been
renamed from ``gitify`` (back) to ``init``.
[tomster]
* Allow the ``help``, ``--version`` and ``fetch`` commands to run outside .svn directories
[tomster]
0.6 - 2010-03-07
----------------
* add a file manifest so that all necessary files will get included for sdist
[proyvind]
* sample update hook for enforcing dcommits to help keeping the svn and git
repositories in sync
[chaoflow]
* updated tests to work with git 1.6.x
[tomster]
* removed deprecated entry points for clone, fetch and commit
[tomster]
0.5 - 2009-08-15 (a.k.a. HAR2009 release)
-----------------------------------------
* Added ``gitify update`` command, which performs a git-svn rebase operation
for the current svn checkout but also handles uncommitted local changes
gracefully (unlike ``git svn`` but like svn does)
* No longer use the logging module for user feedback. That idea was rather
misguided :)
0.4 - 2009-08-11
----------------
* Refactored the entry points to just use gitify. All other commands are now
sub-commands of ``gitify``:
* ``gs-commit`` has been replaced with ``gitify push``
* ``gs-fetch`` has been replaced with ``gitify fetch``
* Added usage and help output for each command.
* Removed the ``gs-clone`` entry point as it was only ever used together with
the main gitify command anyway.
* Use proper logging instead of just printing to stdout
* Added comprehensive tests, including functional tests that cover the entire
update/commit cycle of cloning an svn repository and commiting back to it.
0.3.1 - 2009-07-09
------------------
* BUGFIX: Don't use custom aliases, as they might not be installed.
This resolves http://github.com/tomster/git-svn-helpers/issues#issue/2
* BUGFIX: Explicitly list elementtree as dependency
This resolves http://github.com/tomster/git-svn-helpers/issues#issue/1)
0.3 - 2009-06-09
----------------
* Added the ``gs-commit`` command which helps committing back to svn and
keeping git and svn in sync
0.2b - 2009-06-05
-----------------
* Added the ``gs-fetch`` command which helps keeping the cache up-to-date
0.1b2 - 2009-05-30
------------------
* BUGFIX: get the svn log from the package root (i.e. ``/path/to/foo``)
instead of the locally checked out path (i.e. ``path/to/foo/branches/bar``)
which is usually much younger than the entire package and thus we would miss
revisions in the cloning process!
0.1b1 - 2009-05-30
------------------
* Initial release a.k.a. "Works for me"