headers
FZiegler | 3 Jul 2009 21:40

[Bug 386779] Re: make fails on OS X at "date" call

I ran into the same problem -- the error is

Creating dvc-version.texinfo
date: illegal time format
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]
make[1]: *** [dvc-version.texinfo] Error 1
make: *** [info] Error 2
mini:_.build fz$ 

...because BSD `date' has different flags. Workaround:

=== modified file 'texinfo/Makefile.in'
--- texinfo/Makefile.in	2008-08-23 06:33:26 +0000
+++ texinfo/Makefile.in	2009-07-03 17:50:43 +0000
 <at>  <at>  -79,7 +79,7  <at>  <at> 
 dvc-version.texinfo: $(top_srcdir)/configure
 	 <at> echo Creating $ <at> 
 	 <at> ( echo  <at> set VERSION $(PACKAGE_VERSION) ; \
-	   date '+ <at> set UPDATED %F' -r $< ) > $ <at> 
+	  stat -t'%F' -f' <at> set UPDATED %Sm' $< ) > $ <at> 

 .PHONY: all dvi pdf html info \
 	install uninstall \

Unfortunately this is not a cross-platform solution either, and I dont' think there is an easy POSIX
one-liner we could put here.  (See [1], and compare the BSD and Linux man pages for `date', `stat', `ls' at
[2].)  If you insist on a standard date format, I believe the `automatic' solution is to include `mdate-sh'
in the distribution, as described in (info "(automake) Texinfo")) -- much as we already have `install-sh'.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Reichör | 9 Jul 2009 23:00
Picon

[commit] rev 555: Patch from Thierry Volpiatto: New function xhg-search-regexp-in-log (bound to G in *xhg-log* buffers)

Committed revision 555 to http://bzr.xsteve.at/dvc/

Patch from Thierry Volpiatto: New function xhg-search-regexp-in-log (bound to G in *xhg-log* buffers)
Permalink | Reply | 0 comments |
headers
Stephen Leake | 14 Jul 2009 01:49
Favicon

diff reverse?

I'm exploring the possibility of reversing the order of 'dvc-diff'.

There are two use cases for dvc-diff:

1) I want to see what I've changed in my workspace since the last
commit; show diff _from_ base rev _to_ workspace.

2) I'm reviewing a list of commits by others on my team. The revisions
are all newer than my current workspace. So I want to see changes
_from_ my workspace _to_ a given rev. 

For example, when adding or deleting files, showing the diff in
the wrong order changes a delete to an add, and vice versa, which is
confusing.

Currently, 'dvc-diff rev' shows changes _from_ the rev _to_ the
workspace, which is appropriate for use case 1.

I've hacked in some code in xmtn-dvc-diff (not committed anywhere
yet), that chooses the order by looking at the ancestor relationship
between the workspace base revision, and the diff target revision. It
then computes the diff from the ancestor to the descendant (but
including any changed files in the workspace).

However, monotone itself doesn't support reversing the order; I'm
working on that as well (adding a --reverse option to 'mtn diff').

Do other backends support 'diff --reverse <rev>'?

Do other backends support inquiring about the ancestor relationship of
(Continue reading)

Permalink | Reply | 2 comments |
headers
Samuel Bronson | 14 Jul 2009 05:27
Picon
Gravatar

Re: diff reverse?

On Mon, Jul 13, 2009 at 7:49 PM, Stephen
Leake<stephen_leake <at> stephe-leake.org> wrote:

> Do other backends support inquiring about the ancestor relationship of
> two revs?

... what if there isn't one?
Permalink | Reply | 1 comment |
headers
Stephen Leake | 14 Jul 2009 06:24
Favicon

Re: diff reverse?

Samuel Bronson <naesten <at> gmail.com> writes:

> On Mon, Jul 13, 2009 at 7:49 PM, Stephen
> Leake<stephen_leake <at> stephe-leake.org> wrote:
>
>> Do other backends support inquiring about the ancestor relationship of
>> two revs?
>
> ... what if there isn't one?

That would be one possible result of the query.

But in the two use cases I presented, there is such a relationship.

monotone supports getting all the ancestors or descendants of a
particular revision, on a particular branch. Then dvc searches that
list for the other revision.

--

-- 
-- Stephe
Permalink | Reply | 0 comments |

Gmane