monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Updated Issue 109 - mtn au get_extended_manifest_of Sho


From: code
Subject: [Monotone-devel] Updated Issue 109 - mtn au get_extended_manifest_of Should Default To Current Workspace Like get_manifest_of Does (monotone)
Date: Wed, 24 Nov 2010 12:30:44 GMT

Hello,

The following issue has been updated:

109 - mtn au get_extended_manifest_of Should Default To Current Workspace Like 
get_manifest_of Does
Project: monotone
Status: WontFix
Reported by: Tony Cooper
URL: https://code.monotone.ca/p/monotone/issues/109/
Labels:
 Type:Feature Request
 Priority:Low

Comments (last first):

# By Tony Cooper, Nov 24, 2010:

Hia Thomas,

No that's fine, I understand. I guess the idea of removing the potentially 
useful `default to workspace' feature of get_manifest_of() for the sake of 
consistency is a step in the wrong direction.

I have marked this ticket as wont-fix so as to save further time being wasted 
on it.

Cheers,

Tony.

 Status: WontFix

# By Thomas Keller, Nov 20, 2010:

Hi Tony!

The reason why get_extended_manifest_of doesn't work with only a workspace 
given is because its output would have to deal with workspace changes which 
happened since the base revision. The old get_roster command did that and 
produced something halfwhat usable, but the file size output which we "attach" 
afterwards to the roster format is not easily possible in this scenario and 
trust me, many parts of mtn's internal roster code still scare me and would you 
as well, so I decided to not touch them.

The result is a compromise - have one (extended) format for committed 
changesets and use inventory for uncommitted / workspace changesets. We can 
easily add more fields to inventory from the roster if needed (right now the 
most prominent "recent" addition was the birth revision stanza), but I'd do 
that on individual request.

Thomas.

# By Tony Cooper, Nov 20, 2010:

Ok fair enough, but why does get_manifest_of not do the same? I think it's a 
pity to have this inconsistency.

# By Stephen Leake, Nov 20, 2010:

In general, automate commands don't have default arguments. The design is that 
automate commands are used by front-end tools, which can easily provide all the 
required parameters.

It also simplifies the testing, to not have to test defaults.

# By Tony Cooper, Nov 20, 2010:

get_extended_manifest_of should behave like get_manifest_of in that if no 
revision is given then the details from the current workspace are used.

Why? - Consistency.

Cheers,

Tony.

Output of `mtn version --full`:
-------------------------------
monotone 0.99.1 (base revision: 8973482283db7c36780dce2b54721ccc0f5b7388)
Running on          : Linux 2.6.9-34.EL #1 Sun Mar 19 13:34:16 CST 2006 i686
C++ compiler        : GNU C++ version 4.3.2
C++ standard library: GNU libstdc++ version 20080905
Boost version       : 1_40
SQLite version      : 3.5.9 (compiled against 3.5.9)
Lua version         : Lua 5.1
PCRE version        : 7.6 2008-01-28 (compiled against 7.6)
Botan version       : 1.8.9 (compiled against 1.8.9)
Changes since base revision:
format_version "1"

new_manifest [c1270158b7fa91abf8235ad129b0476943bde1ed]

old_revision [8973482283db7c36780dce2b54721ccc0f5b7388]

  Generated from data cached in the distribution;
  further changes may have been made.



--
Issue: https://code.monotone.ca/p/monotone/issues/109/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]