Re: [fossil-users] Something like rollback
This is close to what I'm looking for. Thank you. -Nick On Thu, Aug 16, 2012 at 7:36 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Wed, 15 Aug 2012 22:13:38 -0400 Simon Tremblay stm...@hotmail.com wrote: On 8/15/12 12:21 PM, Nick Zalutskiy wrote: Ideally I'd like to revert that commit somehow and do two smaller commits thereafter. Since there is no rewriting history in fossil, I assume that this would involve doing a new commit that is the opposite of the incorrect one, and then replying the changes one a time. How would I do this? I'm not familiar enough with fossil to recommend you the best solution for your problem. But, an uncommit feature is currently in the fossil to do list at: http://www.fossil-scm.org/index.html/wiki?name=To+Do+List It has been added on 2012-08-07. I have recently asked about something like `git revert` and have been given an answer [1] that the way to back out a selected commit is to do $ fossil merge --backout that_commit_sha1 I'm not sure you can easily do that replying changes one at a time after that. You could, in theory, get the diff introduced by the reverted commit, save it to a file and then apply it hunk-by-hunk exercising your text editing skills and the `patch` program. 1. http://permalink.gmane.org/gmane.comp.version-control.fossil-scm.user/9691 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Something like rollback
My situation: * Working on a new feature. * Multiple files edited. * Notice a bug in another file, fix it. * Decide to commit just that file with the fix. * Type: fossil com -m Small fix. [and crucially press enter by mistake before specifying the file name to commit] * ALL changes get committed (and synced) under the commit message Small fix. Ideally I'd like to revert that commit somehow and do two smaller commits thereafter. Since there is no rewriting history in fossil, I assume that this would involve doing a new commit that is the opposite of the incorrect one, and then replying the changes one a time. How would I do this? -Nick ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil http does not allow periods in fossil name, fossil server does
Dug through the source a bit. It seems this is by design, from
main.c:cmd_http - main.c:process_one_web_page
/* To avoid mischief, make sure the repository basename contains no
** characters other than alphanumerics, -, /, and _.
*/
for(j=strlen(g.zRepositoryName)+1, k=0; zRepo[j] ki-1; j++, k++){
if( !fossil_isalnum(zRepo[j]) zRepo[j]!='-' zRepo[j]!='/' ){
zRepo[j] = '_';
}
}
This is reasonable, but so are periods in file names. =)
* You should return a not found error if there are illegal characters
versus silently replacing them with an underscore. I did not realize
this would be the case until I looked at the source.
$ fossil clone http://fossils.example.com/repo.1.master local.fossil
will actually fetch /dir/on/host/repo_one_master.fossil
$ fossil clone http://fossils.example.com/repo_1.master local.fossil
will fetch the same thing for no obvious reason,
even if there are two different files, repo_1.master.fossil and
repo.1.master, on the server
* The list of allowed characters should probably be longer, if only
for consistency with 'fossil server'. We can even allow periods and
check the result against file.c:file_is_canonical to avoid said
mischief?
Non of this is catastrophic, but... surprised me nonetheless.
Thanks!
-Nick
On Wed, Jan 18, 2012 at 1:45 AM, Nick Zalutskiy pace...@gmail.com wrote:
I have setup fossil to serve repositories using inetd (xinetd in my case) as
per http://fossil-scm.org/index.html/doc/tip/www/server.wiki
Lets say http://example.com:8585 is serving from /home/fossil/repos and there
are two fossil files in there:
repo1.fossil
repo.name.with.periods.fossil
Then:
$ fossil clone http://example.com:8585/repo1 repo1.fossil
[OK]
$ fossil clone http://example.com:8585/repo.name.with.periods repo2.fossil
fossil: server says: 404 not found
...
At the same time if, on the server, we do 'fossil server', instead of serving
using 'fossil http' + inetd:
$ fossil server --port 8686 /home/fossil/repos/repo.name.with.periods.fossil
Then the earlier clone succeeds:
$ fossil clone http://example.com:8686/repo.name.with.periods repo2.fossil
[NOW OK]
Is this a bug?
-Nick
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil http does not allow periods in fossil name, fossil server does
I have setup fossil to serve repositories using inetd (xinetd in my case) as per http://fossil-scm.org/index.html/doc/tip/www/server.wiki Lets say http://example.com:8585 is serving from /home/fossil/repos and there are two fossil files in there: repo1.fossil repo.name.with.periods.fossil Then: $ fossil clone http://example.com:8585/repo1 repo1.fossil [OK] $ fossil clone http://example.com:8585/repo.name.with.periods repo2.fossil fossil: server says: 404 not found ... At the same time if, on the server, we do 'fossil server', instead of serving using 'fossil http' + inetd: $ fossil server --port 8686 /home/fossil/repos/repo.name.with.periods.fossil Then the earlier clone succeeds: $ fossil clone http://example.com:8686/repo.name.with.periods repo2.fossil [NOW OK] Is this a bug? -Nick ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Behavior of rm, mv, and changes/extra
I'm using fossil for the first time, on a new project -- it hurts how pragmatic and elegant fossil is, I had to try it. Over the years, I've developed some habits from hg and git that I can't seems to reconcile with how fossil does things. Can somebody tell me what I'm missing or how my workflow needs to adapt? I seem to be doing two steps for tasks that I preform dozens of times a day and that took one step in both git and hg. rm, mv: Managing files under source control in fossil is tedious, since I have to do every operation twice. One time for fossil and one time for the file system. Ex: $ fossil rm file1 DELETED file1 $ ls file1 $ rm file1 Is there a reason behind this design decision? I'm on the verge of creating my own wrapper script around fossil to get this done in one step. Especially at early stages of the project I perform these operations frequently. It just feels wrong to have to say the same thing (as I see it) twice. fossil changes; fossil extra; : These guys I just dont get. I had to write an alias in my bashrc just because it was getting really annoying. I use 'hg status' and 'git status' multiple times before I commit to get an instant look at what im doing: what file have I touched AND what new files have I created that I need to remember to add to source control. With fossil I have to execute two commands to get the same amount of information. If I do just fossil changes, I inevitably forget to 'fossil add' something. Again, this is especially relevant during the early stages of a project where things change much more dramatically (at least in my case.) To recap: Why not perform file system changes when fossil is instructed to delete or rename a file? Why not have a single command that gives you ALL differences between your working tree and the repository? Best, -Nick ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
