[Monotone-devel] setup creates _MTN/mtn.db

[Stephen Leake]

A recent change lets setup init a new database _MTN/mtn.db if none is given.

First, this needs to be documented in the manual; both that setup will
init the database if it is not already, and that it provides a default
name.

Second, what is the rationale, both for providing any default name, and
choosing this particular name?

I can see that proving a default db name it makes it easy to start a
totally new project. But it's a significant change, and I'm not happy
with the path.

I'm ok with initializing the database if needed.

Once the project grows a branch that they want to checkout into a
different directory, having the database in /_MTN/mtn.db will
be very odd and confusing; people will wonder if there should be one db
per branch, or one db per workspace.

I think ~/.monotone/mtn.db would be a better place for the default
database.

--
-- Stephe


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] setup creates _MTN/mtn.db

[Thomas Keller]

Am 08.05.10 13:44, schrieb Stephen Leake:
> A recent change lets setup init a new database _MTN/mtn.db if none is given.
> 
> First, this needs to be documented in the manual; both that setup will
> init the database if it is not already, and that it provides a default
> name.

Yes, I forgot that and I'll do it shortly. Thanks for he reminder.

> Second, what is the rationale, both for providing any default name, and
> choosing this particular name?

The rationale is simply to make monotone less database-centric and
verbose with respect to the commands needed to start with a fresh project.

> I can see that proving a default db name it makes it easy to start a
> totally new project. But it's a significant change, and I'm not happy
> with the path.
> 
> I'm ok with initializing the database if needed.
> 
> Once the project grows a branch that they want to checkout into a
> different directory, having the database in /_MTN/mtn.db will
> be very odd and confusing; people will wonder if there should be one db
> per branch, or one db per workspace.
> 
> I think ~/.monotone/mtn.db would be a better place for the default
> database.

Those people who store their databases elsewhere have to specify their
complete path now anyways and setup now basically follows the same
principles like clone (even uses the same path). Beside that, setup even
informs the user that it creates a new database in _MTN/, which clone
currently does not iirc.

So let me repeat again, what I wanted to improve is the situation for
first time users and I personally find a place like ~/.monotone/mtn.db
not a good place at all (what if the user starts another, different
project - should we reuse the same database then?), because its much
hidden and maybe even physically away from the actual workspace setup.

Thomas.

-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en



signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] RFC: lua output redirection

[Thomas Keller]

Am 07.05.10 21:22, schrieb Pasi Parviainen:
> On 7.5.2010 2:50, Thomas Keller wrote:
>>
>> Hi all!
>>
>> I'd like to hear your comments on a small hack which I added to our lua
>> hooks code: output redirection for print() and io.write().
>>
>> The rationale behind this is that lua code (be it hooks or even custom
>> commands), which likes to "talk" to the user, most likely use the above
>> mentioned built-ins. These however work directly on STDOUT and this
>> imposes at least three problems:
>>
>> 1) users cannot distinguish lua output from the application's normal
>> output
>>
>> 2) like 1), but even worse for (remote) stdio: for remote_stdio the
>> problem is that the user does not even see it (while he maybe wants to),
>> while for normal stdio the output possibly leads to parsing errors
> 
> This would really be an issue for a user written commands. I would
> prefer to have old behavior for local interactive and scripting use
> cases, at least in user registered commands context.

The problem is that we don't make much of a difference here code-wise.
You're right that user commands which use plain print() commands would
eventually produce garbled output, but then again what we could do here
is to provide P() and W() functions just as we do for the C++ side and
encourage the explicit usage of io.stdout:write() for anything else.

> The rationale here is that, when user registered commands are used, user
> must be aware of those commands in the first place and the output
> generated must be from those user registered commands.

Sorry, I don't understand that. Could you elaborate a bit?

> Use cases in the context of hooks and remote stdio are different. Is it
> even possible to invoke user written commands thru remote stdio or are
> possibly those messages generated by print from the hooks?

No, remote stdio can only invoke automate commands, just as stdio does.
But we might support Lua commands in automate for the future as well,
why not. Since all automate commands have to write to a special ostream
object, the usage of plain print() calls wouldn't then be possible, though.

Thanks for your feedback,
Thomas.

-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en



signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] RFC: lua output redirection

[Thomas Keller]

Am 08.05.10 07:15, schrieb Stephen Leake:
> Thomas Keller  writes:
>> It would pop up in the progress (p) stream. I'm not sure how lua code is
>> supposed to write basic_io to stdio's main output (m) stream. For
>> non-stdio Lua implementors could still just call io.stdout:write()
> 
> Ok. If we make the assumption that anything written to io.write() is a
> progress message, then I agree that capturing it somehow is more
> important than the details of newlines and stdout vs stderr.
> 
> I think that assumption is reasonable; it's certainly true for my Lua
> code.
> 
> Hmm. I'm not sure that's true in the current tests; does this
> overwriting happen when the mtn tests are running?
> 
> If someone is depending on the current behavior, they can change to
> io.stdout:write().

No, while tester binary uses the same lua wrapper like monotone, it
doesn't uses the lua hooks setup which contains the particular code, so
a print() in a test file still does exactly the same as before.

> Sounds good.

Cool, other opinions?

Thomas.


-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en



signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] Okay I'm tired of exception when aborting windows mtn command...

[Timothy Brownawell]

On 05/03/2010 01:29 PM, Daniel Atallah wrote:

Initially, it looked like this was working nicely and the annoying
crash message no longer appeared when Ctrl+C was issued.

However, it looks like the fix for this has an (at least in my view)
undesirable side effect.
I frequently run something like "mtn commit file1 file2&&  mtn push",
and the the first command tends to be what I cancel (e.g. if I realize
while writing the commit message that I need to add additional files,
etc).
Previously, when the first command was canceled, the exit value was
non-zero and the second command didn't run.  Now, the first command is
indicating successful completion despite the "operation canceled: user
interrupt" message, and the second command runs.

I can't think of a use case where this wold be the desired behavior
(perhaps I'm missing something).


Oops, this should be fixed in 8b38c089e7a11ef78e4ebb332b5d7d8c5cfb0eea. 
Sorry about that.


--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #7220] [NEED TEST] Monotone handles deleted files very ungracefully

[Stephen Leake]

Update of bug #7220 (project monotone):

 Assigned to:None => stephen_leake  
 Open/Closed:Open => In Test

___

Follow-up Comment #4:

since it is not a problem with 0.47, we can just close it.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #7221] [NEED TEST] "monotone cert" should not require its target be on a branch

[Stephen Leake]

Update of bug #7221 (project monotone):

 Assigned to:None => stephen_leake  


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #16636] Invariant triggered when moving a versioned file into an unversioned dir

[Richard Levitte]

Update of bug #16636 (project monotone):

 Assigned to:None => rlevitte   


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #16636] Invariant triggered when moving a versioned file into an unversioned dir

[Richard Levitte]

Update of bug #16636 (project monotone):

 Open/Closed:Open => Analyzed   

___

Follow-up Comment #2:

This operation works perfectly with mtn 0.47.  What happens is that the
directory foo/ gets added to the workspace manifest as well.

My view on this: move to close, bug already fixed.

___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #22914] make on OpenBSD 4.0 exits: Don't know how to make TXT2CFLAGS (make line 8849)

[Richard Levitte]

Update of bug #22914 (project monotone):

 Assigned to:rlevitte => None   


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #22914] make on OpenBSD 4.0 exits: Don't know how to make TXT2CFLAGS (make line 8849)

[Richard Levitte]

Update of bug #22914 (project monotone):

 Assigned to:None => rlevitte   


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #29484] mtn rename hits an invariant for invalid moves

[Richard Levitte]

Update of bug #29484 (project monotone):

 Assigned to:None => rlevitte   


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #7221] [NEED TEST] "monotone cert" should not require its target be on a branch

[Stephen Leake]

Update of bug #7221 (project monotone):

  Status:None => Fixed  
 Open/Closed:Open => In Test

___

Follow-up Comment #2:

0.47 doesn't require a branch for 'mtn cert', but I could not find a test for
it. So I added one. rev efce0af84dbe5a17d9fbcbbcbc13afcfc0d02460

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #8535] [NEED TEST] monotone log has bad defaults outside a working directory

[Stephen Leake]

Update of bug #8535 (project monotone):

 Assigned to:None => stephen_leake  

___

Follow-up Comment #2:

in 0.47, 'mtn log' outside a workspace gives:

   mtn: misuse: workspace required but not found
   mtn: misuse: try passing a --from revision to start at

This is also annoying:
 mtn --db ~/monotone-dbs/mtn.db log --branch net.venge.monotone --last 5
 mtn: option error: unknown option 'branch'

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #8535] [NEED TEST] monotone log has bad defaults outside a working directory

[Stephen Leake]

Update of bug #8535 (project monotone):

  Status:None => Fixed  
 Open/Closed:Open => In Test

___

Follow-up Comment #3:

but this works nicely:

  mtn --db ~/monotone-dbs/mtn.db log --from h:net.venge.monotone --last
5
  mtn: expanding selection 'h:net.venge.monotone'
  mtn: expanded to '3085ca18b6493371676bbd39d757ff29112404bc'
  ...

I think we can just close this one

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #8549] handle tree-layout merge failure sensibly

[Stephen Leake]

Follow-up Comment #1, bug #8549 (project monotone):

need an example; what is an "unresolvable tree layout change"?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #8916] Default database location

[Stephen Leake]

Update of bug #8916 (project monotone):

  Status:None => Fixed  
 Assigned to:None => stephen_leake  
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

current head has a default database location, for 'setup' and 'clone'.

We can close this..

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #8535] [NEED TEST] monotone log has bad defaults outside a working directory

[Thomas Keller]

Follow-up Comment #4, bug #8535 (project monotone):

For first time users it might still be cool to have -b foo resolving
automatically to --from h:foo, no? And this should also reasonable easy to
implement...

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #9231] Monotone does not handle symlinks

[Stephen Leake]

Follow-up Comment #4, bug #9231 (project monotone):

I'm not clear what the original problem is. 

Win32 certainly does not support symlinks; trying to add mtn code to fake
that is not a good idea.

Cygwin does support symlinks; use that instead.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #8916] Default database location

[Thomas Keller]

Follow-up Comment #2, bug #8916 (project monotone):

One extra cookie for the person implementing this default for the last
remaining command, 'import'... :)

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #9235] [NEED TEST] File in repository with \ instead of / directory separator

[Stephen Leake]

Update of bug #9235 (project monotone):

 Assigned to:None => stephen_leake  
 Summary: [NEED TEST] File in repository with \ instead of /
directory separator => [NEED TEST] File in repository with  instead of /
directory separator


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #9231] Monotone does not handle symlinks

[Thomas Keller]

Follow-up Comment #5, bug #9231 (project monotone):

The problem is that symlinks are simply lost, while they should get a special
file attribute which stores the original symlink and creates that instead on
update / checkout / revert on supported platforms:

$ mtn setup .
$ touch foo
$ ln -s foo bar
$ mtn add bar
$ mtn ci -m "test"
$ file -h bar
bar: symbolic link to foo
$ rm bar
$ mtn revert --missing
$ file -h bar
bar: UTF-8 Unicode text



___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #9231] Monotone does not handle symlinks

[Stephen Leake]

Follow-up Comment #6, bug #9231 (project monotone):

Just to clarify; this is talking about symlinks within the workspace, not
symlinks to files outside the workspace. It would be useful for mtn to
preserve in-workspace symlinks. For example, /etc often has them.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #9235] [NEED TEST] File in repository with \ instead of / directory separator

[Stephen Leake]

Update of bug #9235 (project monotone):

  Status:None => Fixed  
 Open/Closed:Open => In Test
 Summary: [NEED TEST] File in repository with \ instead of /
directory separator => [NEED TEST] File in repository with  instead of /
directory separator

___

Follow-up Comment #3:

mtn currently canonicalizes paths:

C:Projects>mtn add barbaz
mtn: adding bar to workspace manifest
mtn: adding bar/baz to workspace manifest

We can close this item

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #9269] [NEED TEST] monotone log doesn't understand windows directory separator

[Stephen Leake]

Update of bug #9269 (project monotone):

 Assigned to:None => stephen_leake  


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #29484] mtn rename hits an invariant for invalid moves

[Richard Levitte]

Update of bug #29484 (project monotone):

  Status:None => Fixed  
 Open/Closed:Open => In Test


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #12773] show which branch a tag belongs to

[Derek Scherger]

Update of bug #12773 (project monotone):

 Assigned to:None => dscherger  


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #29484] mtn rename hits an invariant for invalid moves

[Richard Levitte]

Follow-up Comment #1, bug #29484 (project monotone):

Added a few checks to see if a file to be moved is the same as the
destination and have mtn issue a warning when that happens.

This follows the same semantics as ths usual Unix mv(1), and will therefore
only warn, not trigger an error and therefore not generate a exit code other
than 0.

___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #9269] [NEED TEST] monotone log doesn't understand windows directory separator

[Stephen Leake]

Update of bug #9269 (project monotone):

  Status:None => Fixed  

___

Follow-up Comment #4:

added a test. rev d8a2add47319b83ac7657d34df8f69c028b61208

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #13706] allow passphraseless keys

[Richard Levitte]

Update of bug #13706 (project monotone):

  Status:None => Fixed  
 Assigned to:None => rlevitte   
 Open/Closed:Open => In Test

___

Follow-up Comment #2:

In #28809, it is said that empty passphrases are allowed.  I cannot say
exactly in what version this happened, unfortunately.

___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #16021] monotone co [directory] not usage quite clear

[Richard Levitte]

Update of bug #16021 (project monotone):

 Assigned to:None => rlevitte   


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #12455] MT 0.16 can't access, if DB stored on NFS

[Stephen Leake]

Update of bug #12455 (project monotone):

  Status:None => Wont Fix   
 Assigned to:None => stephen_leake  
 Open/Closed:Open => In Test

___

Follow-up Comment #6:

Since this is a problem with the NFS filesystem not providing locking, I
don't think mtn can do anything about it.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #16021] monotone co [directory] not usage quite clear

[Richard Levitte]

Update of bug #16021 (project monotone):

  Status:None => Fixed  
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

Today, the usage says the following:


  Syntax specific to 'mtn co':

co [KATALOG]

  Description for 'mtn co':

Checks out a revision from the database into a directory.

If a revision is given, that's the one that will be checked out. 
Otherwise,
it will be the head of the branch (given or implicit).  If no directory
is
given, the branch name will be used as directory.

Aliases: checkout.

That should be enough to explain what will happen, no?

___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #16069] log message handling assumes everything is in UTF-8

[Richard Levitte]

Update of bug #16069 (project monotone):

 Assigned to:None => rlevitte   


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #16069] log message handling assumes everything is in UTF-8

[Richard Levitte]

Update of bug #16069 (project monotone):

  Status:None => Fixed  
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

This was fixed in version 0.30, according to NEWS:


Bug fixes:

- While changelog messages have always been defined to UTF-8,
  we were not properly converting messages from the user's
  locale.  This has now been fixed.


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #8549] handle tree-layout merge failure sensibly

[Timothy Brownawell]

Follow-up Comment #2, bug #8549 (project monotone):

This would be for example merge("rename a to b", "rename a to c") or
merge("rename x to z", "rename y to z") and the like. Anything that causes a
merge conflict when mark-merging the parent or name of a node_t.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #12774] show lifetime of a branch

[Stephen Leake]

Update of bug #12774 (project monotone):

Severity:  3 - Normal => 1 - Wish   


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #12773] show which branch a tag belongs to

[Derek Scherger]

Update of bug #12773 (project monotone):

 Open/Closed:Open => In Test


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #12773] show which branch a tag belongs to

[Derek Scherger]

Update of bug #12773 (project monotone):

  Status:None => Fixed  


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #13409] mixup of different branches within working copy

[Stephen Leake]

Update of bug #13409 (project monotone):

Severity:  3 - Normal => 1 - Wish   

___

Follow-up Comment #1:

I added the Lua command 'change_workspace' to facilitate writing Lua
functions that operate on sibling workspaces. That's at least similar to this
request.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #13597] monotone update -b newbranch exhibits incorrect behaviour

[Stephen Leake]

Update of bug #13597 (project monotone):

 Assigned to:None => stephen_leake  


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #27929] Don't use excessive amounts of entropy

[Derek Scherger]

Update of bug #27929 (project monotone):

  Status:None => Wont Fix   
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands

[Richard Levitte]

Update of bug #28805 (project monotone):

 Assigned to:None => rlevitte   


___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #20447] mtn diff fails inside of a renamed directory

[Derek Scherger]

Update of bug #20447 (project monotone):

 Assigned to:None => dscherger  
  mtn version --full: C:\dev\forta>mtn --full-version

monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b)  
  
Running on  : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack
2) 
on ia32 (level 6, rev 3846)  
  
C++ compiler: GNU C++ version 3.4.2 (mingw-special)  
  
C++ standard library: GNU libstdc++ version 20040907 
  
Boost version   : 1_33_1 
  
Changes since base revision: 
  
format_version "1"   
  
 
  
new_manifest [33fa9f84dee6ec2e1bde81b607a067befbe2fc3e]  
  
 
  
old_revision [f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b]  
  
 
  
patch "Makefile.am"  
  
 from [ecc00e0b8e9b5350157a1922e430ade4508d31bd] 
  
   to [a52adc6a23a4bedf2d636a6c3e91cd46ce900a35] 
  
 
   => C:devforta>mtn --full-version   
 
monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b)  
  
Running on  : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack
2) 
on ia32 (level 6, rev 3846)  
  
C++ compiler: GNU C++ version 3.4.2 (mingw-special)  
  
C++ standard library: GNU libstdc++ version 20040907 
  
Boost version   : 1_33_1 
  
Changes since base revision: 
  
format_version "1"   
  
 
  
new_manifest [33fa9f84dee6ec2e1bde81b607a067befbe2fc3e]  
  
 
  
old_revision [f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b]  
  
 
  
patch "Makefile.am"  
  
 from [ecc00e0b8e9b5350157a1922e430ade4508d31bd] 
  
   to [a52adc6a23a4bedf2d636a6c3e91cd46ce900a35] 
  
 
  

___

Follow-up Comment #1:

0.45 and 0.48dev fail less badly

$ mtn mv unix foobar
$ echo foobar >foobar/cputime.cc
$ mtn diff foobar/cputime.cc
mtn: misuse: file unix/cputime.cc does not exist

but something is still wrong here



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands

[Richard Levitte]

Follow-up Comment #1, bug #28805 (project monotone):

Just a though, would it be enough if --anonymous was added?

___

Reply to this item at:

  

___
  Meddelandet skickades via/av Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #22417] fatal botan error if unreadable files are encountered in a workspace

[Derek Scherger]

Follow-up Comment #2, bug #22417 (project monotone):

Monotone currently also fails for missing files which are somewhat similar to
unreadable files. Perhaps we should still fail but with a nicer message rather
than a hard crash.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #8396] make merkle tree hash not include dormancy bitmask

[Timothy Brownawell]

Update of bug #8396 (project monotone):

  Status:None => Fixed  
 Assigned to:None => tbrownaw   
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

I see nothing about dormancy is merkle_tree.??, and nothing that looks like
it would make node's hashes needlessly differ. So this must have been fixed
sometime in the last 6 years.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #5672] "monotone explain"

[Timothy Brownawell]

Update of bug #5672 (project monotone):

  Status:None => Wont Fix   
 Assigned to:None => tbrownaw   
 Open/Closed:Open => In Test

___

Follow-up Comment #2:

I don't think this is needed now that we have netsync instead of
packets-over-nntp. I think pretty much the only packets used regularly now are
keypairs (in the keystore) and pubkeys (for requesting push access).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands

[Thomas Keller]

Follow-up Comment #2, bug #28805 (project monotone):

Would certainly be possible as simple fix. 

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #19597] mtn should not allow files to be both ignored and in the workspace

[Timothy Brownawell]

Update of bug #19597 (project monotone):

 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

This has been "Wontfix" for 3 months, it should probably be closed.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #16895] Better error reporting in permission-denied scenarios

[Timothy Brownawell]

Update of bug #16895 (project monotone):

  Status:None => Fixed  
 Assigned to:None => tbrownaw   
 Open/Closed:Open => In Test


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove

[Timothy Brownawell]

Update of bug #17878 (project monotone):

 Assigned to:None => tbrownaw   

___

Follow-up Comment #2:

I think what we want to do here is:
 * 'disapprove' warns if it creates divergence
 * 'status' (and the pre-filled comments in the commit message editor) notes
whether the current revision is a head of the current branch or a commit would
create divergence

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove

[Thomas Keller]

Follow-up Comment #3, bug #17878 (project monotone):

+1 for that, but I'd personally wait with the second point until Derek landed
the changelog editor branch in mainline (or if you want to go for it, base
your work on his branch).

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove

[Ludovic Brenta]

Follow-up Comment #4, bug #17878 (project monotone):

In the scenario I described, "disapprove" cannot warn when it creates
divergence because it does not create divergence.  Indeed, it is "commit" that
later creates the divergence.

IIUC, adding a message in the changelog works only if the user does not pass
-m "comment" to "commit" (which, personally, I do quite often); -m would
defeat your helpful message.

Therefore, -1 on your proposed solution :)

What is wrong with my two proposed solutions?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] setup creates _MTN/mtn.db

[Zack Weinberg]

On Sat, May 8, 2010 at 5:08 AM, Thomas Keller  wrote:
> Am 08.05.10 13:44, schrieb Stephen Leake:
>> Second, what is the rationale, both for providing any default name, and
>> choosing this particular name?
>
> The rationale is simply to make monotone less database-centric and
> verbose with respect to the commands needed to start with a fresh project.
>
>> I can see that proving a default db name it makes it easy to start a
>> totally new project. But it's a significant change, and I'm not happy
>> with the path.
>>
>> I'm ok with initializing the database if needed.
>>
>> Once the project grows a branch that they want to checkout into a
>> different directory, having the database in /_MTN/mtn.db will
>> be very odd and confusing; people will wonder if there should be one db
>> per branch, or one db per workspace.

I sympathise with Stephen here a bit - Monotone's ability to share one
database among many workspaces is a significant difference from Git
and Mercurial, and one that should be up-front rather than buried.

How about putting the database in the parent directory of the checkout
and naming it something like _store.mtn by default?

zw


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

[Monotone-devel] [bug #17878] Usability: too easy to accidentally fork after merge or disapprove

[Timothy Brownawell]

Follow-up Comment #5, bug #17878 (project monotone):

Oh, hm, it doesn't.

I don't particularly like the idea of making 'commit' become unpredictably
interactive. It means there's an extra step between "commit, go back to
coding" which is "wait to see if 'commit' asked anything", and it breaks "run
'make check && mtn ci -m foo && mtn sy', go do something else for a while
while that runs", and it just doesn't seem that good an idea to have it be
"you have to watch this to see if it needs input, but it usually doesn't".

So that leaves the other option, having 'merge', 'disapprove',
'merge_into_dir', 'propagate', and maybe 'explicit_merge', 'pull', 'sync',
'approve', and 'suspend' update the workspace (and take a --no-update flag to
turn this off). But I like having things be orthogonal too (and suspect it
helps with learning the concepts), and this would break that somewhat.

I suppose practicality is probably more important here than prettiness, so
what would be good criteria for updating? Say, the base revision goes from
being a head to not being a head (if it's already not a head, presumably the
user did 'update -r ...' and wants it to stay there) and doesn't contain any
uncommitted changes (making them possibly go through conflict resolution when
they didn't ask for it seems impolite)? This still leaves the potential for
confusion from having multiple workspaces (only one would be updated) and
different behavior of non-workspace commands based on being in a workspace and
on *accidentally* not being at a head revision (say because your last pull was
done outside a workspace). Does the extra convenience outweigh the potential
for extra (different) confusion?

I suppose I'll add '--update' and '--no-update' flags for those commands, and
we can go bikeshed later on which should be the default.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.nongnu.org/



___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] setup creates _MTN/mtn.db

[Thomas Keller]

Am 09.05.10 01:33, schrieb Zack Weinberg:
> On Sat, May 8, 2010 at 5:08 AM, Thomas Keller  wrote:
>> Am 08.05.10 13:44, schrieb Stephen Leake:
>>> Second, what is the rationale, both for providing any default name, and
>>> choosing this particular name?
>>
>> The rationale is simply to make monotone less database-centric and
>> verbose with respect to the commands needed to start with a fresh project.
>>
>>> I can see that proving a default db name it makes it easy to start a
>>> totally new project. But it's a significant change, and I'm not happy
>>> with the path.
>>>
>>> I'm ok with initializing the database if needed.
>>>
>>> Once the project grows a branch that they want to checkout into a
>>> different directory, having the database in /_MTN/mtn.db will
>>> be very odd and confusing; people will wonder if there should be one db
>>> per branch, or one db per workspace.
> 
> I sympathise with Stephen here a bit - Monotone's ability to share one
> database among many workspaces is a significant difference from Git
> and Mercurial, and one that should be up-front rather than buried.
> 
> How about putting the database in the parent directory of the checkout
> and naming it something like _store.mtn by default?

In general I agree, but I fear a behaviour is much more unpredictable
and hard to implement than just putting the database into the
bookkeeping root. Imagine what happens if the setup / clone path is
writable, but the parent of this path is not, what if there already
exists a db in the parent path with the same name, et cetera pp.

Maybe this is all solvable with more path / rights checking and unique
naming, but still, whatever we come up with afterwards, I fear it will
look equally if not even more clumsy compared to what we have now, a
self-contained workspace.

Maybe we could make it easier to "extract", or better "move" an
internalized database to an external place and vice versa, so people
don't have to mess with _MTN/options by hand? Then maybe
$HOME/.monotone/databases/.mtn is a good default,
similar to what Stephen proposed. We could add more management features
there, f.e. a "list databases" command which lists available known
databases, a way to find a database only by its name (ie. -d foo would
look for and find $HOME/.monotone/databases/foo.mtn), we could "connect"
databases and workspaces by adding known workspaces of a database as db
variables and list those as well in the database list. There could be a
hook "get_default_database_location" which could be altered by the user
to a different path than the default one underknees $HOME, stuff like that.

Thomas.

-- 
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en



signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] setup creates _MTN/mtn.db

[hendrik]

On Sat, May 08, 2010 at 02:08:35PM +0200, Thomas Keller wrote:
> Am 08.05.10 13:44, schrieb Stephen Leake:
> > A recent change lets setup init a new database _MTN/mtn.db if none is given.
> > 
> > First, this needs to be documented in the manual; both that setup will
> > init the database if it is not already, and that it provides a default
> > name.
> 
> Yes, I forgot that and I'll do it shortly. Thanks for he reminder.
> 
> > Second, what is the rationale, both for providing any default name, and
> > choosing this particular name?
> 
> The rationale is simply to make monotone less database-centric and
> verbose with respect to the commands needed to start with a fresh project.
> 
> > I can see that proving a default db name it makes it easy to start a
> > totally new project. But it's a significant change, and I'm not happy
> > with the path.
> > 
> > I'm ok with initializing the database if needed.
> > 
> > Once the project grows a branch that they want to checkout into a
> > different directory, having the database in /_MTN/mtn.db will
> > be very odd and confusing; people will wonder if there should be one db
> > per branch, or one db per workspace.
> > 
> > I think ~/.monotone/mtn.db would be a better place for the default
> > database.
> 
> Those people who store their databases elsewhere have to specify their
> complete path now anyways and setup now basically follows the same
> principles like clone (even uses the same path). Beside that, setup even
> informs the user that it creates a new database in _MTN/, which clone
> currently does not iirc.
> 
> So let me repeat again, what I wanted to improve is the situation for
> first time users and I personally find a place like ~/.monotone/mtn.db
> not a good place at all (what if the user starts another, different
> project - should we reuse the same database then?), because its much
> hidden and maybe even physically away from the actual workspace setup.

Last thing I want is to create a random data base when I just forget to 
mention what database I want to use.

-- hendrik


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Re: [Monotone-devel] setup creates _MTN/mtn.db

[Richard Levitte]

In message <4be6066a.20...@thomaskeller.biz> on Sun, 09 May 2010 02:48:42 
+0200, Thomas Keller  said:

me> Maybe we could make it easier to "extract", or better "move" an
me> internalized database to an external place and vice versa, so people
me> don't have to mess with _MTN/options by hand? Then maybe
me> $HOME/.monotone/databases/.mtn is a good default,
me> similar to what Stephen proposed. We could add more management features
me> there, f.e. a "list databases" command which lists available known
me> databases, a way to find a database only by its name (ie. -d foo would
me> look for and find $HOME/.monotone/databases/foo.mtn), we could "connect"
me> databases and workspaces by adding known workspaces of a database as db
me> variables and list those as well in the database list. There could be a
me> hook "get_default_database_location" which could be altered by the user
me> to a different path than the default one underknees $HOME, stuff like that.

THIS idea, I like!  +10 or something ;-)

(and while we're on that debate, I strongly dislike the _MTN/mtn.db
idea, for a very simple reason; I sometimes experiment with something
as a start in some temporary directory, and usually regard the
database as safe while the workspace isn't...  with this default, it
suddenly becomes dangerous to just toss away the workspace when it's
not needed any more.  I regard this default as unsafe practice, and
would rather like it do be something like - following your thoughts
above here - ~/.monotone/databases/_default.mtn)

Cheers,
Richard

-- 
Richard Levitte rich...@levitte.org
http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish


___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel