[Monotone-devel] Merging outside monotone?

2005-10-09 Thread Wim Oudshoorn
After using monotone for a while I am becoming of the opinion
that the current merging behaviour is not very user friendly.

The problems I have come down to three problems, in various
degrees of annoyances

1) The necessity of having a merge tool.

2) The fact that one mistake in merging can
   let you lose all merges upto that point.

3) The order of merging imposed by monotone.

I will first detail the 3 points above conclude
with a short description of an alternative 
way of handling to provoke a discussion.


1 - Need to have a merge tool
-
This is a minor annoyance.  But I work
monotone on MS windows computers, and on those
machines it is not very customary to have one
of the default merge tools available.

This makes it slightly more complicated to start using
monotone, it is one more tool to install.  
Otherwise you could just copy the monotone executable
and start using it.  

Also finding a merge tool that handles source files and
binary files in a good way is difficult and configuring
monotone to use different merging algorithms depending
on the file I have not dared to attempt yet.

2 - Merge mistakes loses merges already done
-
If you are in a big project and have a complicated merge
and halfway you forget to save your merged file and exit
the merge tool monotone will see that you have not merged
that file and revert all files.  
This means that all the merges you had performed you have 
to do again.  
This is quite annoying.

3 - Order of merging

Monotone forces you to merge all the files one by one
in an order imposed by monotone.  
But sometimes (quite often) in cases of a conflict
you want to see in which files there are conflicts and
examine the 'important' files first. 
Also I am not always merging in a linear fashion.  


Brainstorm section of an alternative

DISCLAIMER:  I just thought this up, so
 it could well be that this is
 nonsense.

If instead of the current mechanism it would
be possible to have something like:

   monotone --merge-command=directory-dump merge

which will write out all the conflicts in a directory
structure like:

TEMP/Ancestor/file-1
TEMP/Ancestor/file-2

TEMP/Left/file-1
TEMP/Left/file-2

TEMP/Right/file-1
TEMP/Right/file-2

TEMP/Merged/file-1
TEMP/Merged/file-2

Now the user can use its favorite merge tool on these directories
and after the user is done do something like:

monotone --merge-command=directory-input merge


Of course monotone in this case will check that the content
of the directory makes sense, so it probably needs to:

* Check by reading a file in the TEMP directory that
  the revisions of Left and Right and Ancestor makes sense 
  in the database
 
* The Merge directory indeed resolves all conflicts.  That
  is, the user has put a file there for all the files 
  need resolution.

If one of the conditions is wrong, monotone complains and
let the user fix the problem.


Wrapper tools integration
-
Another reason I would like such a structure is the fact
that I am writing a pclcvs like emacs mode for monotone.
I would prefere to do my merging in this mode as well.
For this it would be nice if I could have such
a directory structure and present the user with
tools to merge the files one by one and commit the merge
result in the end. 
With the current behaviour I don't see how I could accomplish
that.

Wim Oudshoorn.




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


[Monotone-devel] Re: Merging outside monotone?

2005-10-09 Thread Lapo Luchini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Wim Oudshoorn wrote:
 If instead of the current mechanism it would
 be possible to have something like

This is scary: believe or not I was just about to propose something
close to that myself =)
(that is: FWIW I completely agree about the proposal)

- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iEYEARECAAYFAkNJLtIACgkQaJiCLMjyUvshuwCfYPOWV2rRTJ7/AaDabVq7QKvb
6AcAoLzC5m1jnKSJScNxjppLZqzEL00z
=RPNF
-END PGP SIGNATURE-



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


Re: [Monotone-devel] Re: monotone setup failure

2005-10-09 Thread Peter Portante







FYI: Mistyping a - gives the following error:

[frodo:Personal/School/CSG280] portante% monotone db init -db=./temp.db
monotone: misuse: monotone db doesn't use the option --branch



On 10/8/05 4:29 PM, Nathaniel Smith [EMAIL PROTECTED] wrote:

 On Sat, Oct 08, 2005 at 02:42:05PM -0400, Peter Portante wrote:
Also, the file system is an afp remote mount. Probably a file locking
issue?
 
 Likely; schema extraction issues are often a sign of locking trouble.
 
 Can you send the output of running the same command with --debug?

It is not quite the same command as I had to change the database to a new
one since I am using the original reported earlier. But the schema message
does get displayed.

Hope this helps, thanks.

-peter

[rockets:School/CSG280/pt-1.2] portante% monotone --debug --db=./temp.db
--branch=edu.neu.ccs.csg280.topc.debug setup doc
monotone: started up on Darwin 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30
20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power Macintosh
monotone: command line: 'monotone', '--debug', '--db=./temp.db',
'--branch=edu.neu.ccs.csg280.topc.debug', 'setup', 'doc'
monotone: set locale: LC_ALL=C
monotone: initial abs path is:
/Volumes/portante/Documents/Personal/School/CSG280/pt-1.2
monotone: converting 8 bytes from US-ASCII to UTF-8
monotone: converting 7 bytes from US-ASCII to UTF-8
monotone: converting 14 bytes from US-ASCII to UTF-8
monotone: converting 38 bytes from US-ASCII to UTF-8
monotone: converting 5 bytes from US-ASCII to UTF-8
monotone: converting 3 bytes from US-ASCII to UTF-8
monotone: initializing from directory
/Volumes/portante/Documents/Personal/School/CSG280/pt-1.2
monotone: searching for 'MT' directory with root '/'
monotone: 'MT' not found in
'/Volumes/portante/Documents/Personal/School/CSG280/pt-1.2' with '' removed
monotone: 'MT' not found in
'/Volumes/portante/Documents/Personal/School/CSG280' with 'pt-1.2' removed
monotone: 'MT' not found in '/Volumes/portante/Documents/Personal/School'
with 'CSG280/pt-1.2' removed
monotone: 'MT' not found in '/Volumes/portante/Documents/Personal' with
'School/CSG280/pt-1.2' removed
monotone: 'MT' not found in '/Volumes/portante/Documents' with
'Personal/School/CSG280/pt-1.2' removed
monotone: 'MT' not found in '/Volumes/portante' with
'Documents/Personal/School/CSG280/pt-1.2' removed
monotone: 'MT' not found in '/Volumes' with
'portante/Documents/Personal/School/CSG280/pt-1.2' removed
monotone: search for 'MT' ended at '/' with
'Volumes/portante/Documents/Personal/School/CSG280/pt-1.2' removed
monotone: '/MT' does not exist
monotone: Lua::ok(): failed = 0
monotone: skipping nonexistent rcfile
'/Volumes/Users/portante/.monotone/monotonerc'
monotone: skipping nonexistent rcfile 'MT/monotonerc'
monotone: executing command 'setup'
monotone: statement cache statistics
monotone: prepared 0 statements
monotone: fatal: std::runtime_error: failure extracting schema from
sqlite_master
monotone: 
monotone: this is almost certainly a bug in monotone.
monotone: please send this error message, the output of 'monotone
--full-version',
monotone: and a description of what you were doing to
[EMAIL PROTECTED]
monotone: discarding debug log (maybe you want --debug or --dump?)




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


Re: [Monotone-devel] Merging outside monotone?

2005-10-09 Thread Matthew A. Nicholson

Wim Oudshoorn wrote:

After using monotone for a while I am becoming of the opinion
that the current merging behaviour is not very user friendly.

The problems I have come down to three problems, in various
degrees of annoyances

1) The necessity of having a merge tool.

2) The fact that one mistake in merging can
   let you lose all merges upto that point.

3) The order of merging imposed by monotone.



I have always like the way monotone handles merging vs CVS.  I always 
hated cvs just dumping unmerged files all over the place.  Also I like 
the ability to use vimdiff to merge my files.  I don't think this is a 
bad option to have as long as it does not interfere with the current 
behavior.

--
Matthew A. Nicholson
Matt-Land.com


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


[Monotone-devel] Broken monotone 0.19 database

2005-10-09 Thread Glen Ditchfield
I have a monotone database, used with monotone 0.19, that now gives me 
invariant violation messages.  To complicate matters, I ran monotone db 
update with monotone 0.23 in my working directory, without saving the MT 
directory.  Fortunately nothing irreplacable is in the database, but if 
there's an easy way out of this mess, I'd like to hear about it...

If I copy the original 0.19 database back to the original location, monotone 
0.19 --full-version says 
--
monotone 0.19 (base revision: 168adf9537ff136c9b7fe7faad5991f92859390d)
Running on: Linux 2.6.8-24.18-default #1 Fri Aug 19 11:56:28 UTC 2005 i686
Changes since base revision:

new_manifest [52a617d908ac6c4bb5b837ce5306f75155dc59ef]

old_revision [168adf9537ff136c9b7fe7faad5991f92859390d]
old_manifest [a9ee1d741b855fdcc0d038d64d913cef70da72f5]

patch po/monotone.pot
 from [10e6d7cbad87eaa0dbe35c803cafa371567f024b]
   to [0465f6ac8d09fac5938ac067747b179aca677b67]


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

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

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

monotone 0.19 --debug status says
-
monotone: started up on Linux 2.6.8-24.18-default #1 Fri Aug 19 11:56:28 UTC 
2005 i686
monotone: command line: 'monotone', '--debug', 'status'
monotone: set locale: LC_CTYPE=en_US.UTF-8, LC_MESSAGES=en_US.UTF-8
monotone: initial path is /home/gjditchf
monotone: searching for 'MT' directory with root '/'
monotone: search for 'MT' ended at '/home/gjditchf' with '' removed
monotone: initializing from directory /home/gjditchf
monotone: found working copy directory /home/gjditchf
monotone: options path is MT/options
monotone: branch name is 'ca.mb.ditchfield.home.gjditchf'
monotone: local dump path is MT/debug
monotone: setting dump path to MT/debug
monotone: skipping nonexistent rcfile '/home/gjditchf/.monotone/monotonerc'
monotone: opening rcfile 'MT/monotonerc' ...
monotone: 'MT/monotonerc' is ok
monotone: executing status command
monotone: options path is MT/options
monotone: revision path is MT/revision
monotone: loading revision id from MT/revision
monotone: db.fetch(SELECT id FROM 'revisions' WHERE id = 
'612353df0c7aadbb4b57d7abf938c2638a46cefc')
monotone: db.fetch(SELECT data FROM revisions WHERE id = 
'612353df0c7aadbb4b57d7abf938c2638a46cefc')
monotone: old manifest is 698ce66b947445bbd6b39206fcf61d03734176d3
monotone: db.fetch(SELECT id FROM 'manifest_deltas' WHERE id = 
'698ce66b947445bbd6b39206fcf61d03734176d3')
monotone: db.fetch(SELECT id FROM 'manifests' WHERE id = 
'698ce66b947445bbd6b39206fcf61d03734176d3')
monotone: db.fetch(SELECT id FROM 'manifests' WHERE id = 
'698ce66b947445bbd6b39206fcf61d03734176d3')
monotone: db.fetch(SELECT data FROM 'manifests' WHERE id = 
'698ce66b947445bbd6b39206fcf61d03734176d3')
monotone: old manifest has 3320 entries
monotone: work path is MT/work
monotone: checking for un-committed work file MT/work
monotone: read rearrangement from MT/work
monotone: restriction includes delete file .kde/share/config/konq_history
monotone: restriction includes delete file .kde/share/config/ksmserverrc
monotone: restriction includes delete file .kde/share/config/ksslpolicies
monotone: restriction includes delete file .kde/share/config/susewatcherrc
monotone: restriction includes delete file .qt/qt_plugins_3.3rc
monotone: restriction includes delete dir .kde/share/apps/kcookiejar
monotone: path_component.cc:53: invariant 'I(!null_name(*i))' violated
monotone: fatal: std::logic_error: path_component.cc:53: invariant 
'I(!null_name(*i))' violated



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


Re: [Monotone-devel] Broken monotone 0.19 database

2005-10-09 Thread Nathaniel Smith
On Sun, Oct 09, 2005 at 10:48:19PM -0500, Glen Ditchfield wrote:
 I have a monotone database, used with monotone 0.19, that now gives me 
 invariant violation messages.  To complicate matters, I ran monotone db 
 update with monotone 0.23 in my working directory, without saving the MT 
 directory.  Fortunately nothing irreplacable is in the database, but if 
 there's an easy way out of this mess, I'd like to hear about it...

I'm afraid I don't quite understand the problem.  You have a database
you've been using with 0.19.  It started giving you problems.  You
tried upgrading to monotone 0.23 (and running the migration commands
like 'db migrate', I guess?), and it still gave you problems (and
corrupted your MT/revision file to boot)?  So then you restored the
database backup you had sensibly made before running 'db migrate', and
went back to 0.19, and it still caused problems?

If all that's right, can we get a run of 'monotone status --debug'
done against the migrated database, using monotone 0.23?  0.23 has
somewhat better debugging info, and we'll be much more familiar with
the code :-).

Also, is the database itself available to poke at?

(Note, BTW, that uncorrupting MT/revision is pretty easy; the file
just contains a single revision hash, which is the revision you
originally checked out or updated to (so monotone knows what the stuff
in the working is based on, which it needs to know so it can figure
out what stuff you've just changed and what stuff started out the way
it is).  To uncorrupt it, just figure out what revision you _were_
working off of, and do 'echo that hash  MT/revision'.)

-- Nathaniel

-- 
The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer.

This email may be read aloud.


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


Re: [Monotone-devel] Bug in annotate, renamed files?

2005-10-09 Thread Emile Snyder
Is this in a project that you could let me see, or proprietary code?  It
would make it much easier to debug if I could do a pull of your project
db.

thanks,
-emile

On Sun, 2005-10-09 at 14:55 +0200, Wim Oudshoorn wrote:
 In one project containing 3 files the command
 
 monotone annotate file
 
 files on 2 of the 3 files.  Both files that fail have been
 renamed in the past, but I am not sure that is the reason.
 Also both files give a different error.  
 I tried this with version 0.20 and version 0.23 and both failed.
 
 The following description comes from version 0.23, the prebuild
 mac os x binary.  Full version information is at the end of this mail.
 
 File one:  e-monotone.el
 
 
 Error:
 
   monotone: fatal: std::logic_error: ../annotate.cc:550: invariant
 'I(delta_entry_dst(fdelta_iter) == work_unit.node_fid)' violated
   monotone: 
   monotone: 
   monotone: this is almost certainly a bug in monotone.
   monotone: please send this error message, the output of 'monotone 
 --full-version',
   monotone: and a description of what you were doing to [EMAIL PROTECTED]
   monotone: wrote debugging log to /Users/woudshoo/src/em-a/MT/debug
 
 
 Debug file ends with:
 
   do_annotate_node processing edge 
 from parent 21454253c9477ac8b44c9de7b46c21e69c34456c 
 to child a4660bef29785e139533ea07420d0857f45fac54
 
   file wims-monotone.el in parent revision 
 21454253c9477ac8b44c9de7b46c21e69c34456c is wims-monotone.el
   ../annotate.cc:550: invariant 'I(delta_entry_dst(fdelta_iter) == 
 work_unit.node_fid)' violated
   saving current work set: 0 items
   finished saving work set
   
 
 Full debug file:
 
 
 
 
 File two: e-monotone.texi
 
 
 Error:
 
   monotone: fatal: std::logic_error: ../annotate.cc:455: 
   invariant 'I(file_interned.size() == other.file_interned.size())' 
 violated
   monotone: 
   monotone: 
   monotone: this is almost certainly a bug in monotone.
   monotone: please send this error message, the output of 'monotone 
 --full-version',
   monotone: and a description of what you were doing to [EMAIL PROTECTED]
   monotone: wrote debugging log to /Users/woudshoo/src/em-a/MT/debug
 
 Debug file end with:
 
   do_annotate_node processing edge 
  from parent 21454253c9477ac8b44c9de7b46c21e69c34456c 
  to child 4684e0611ebc668312162c3d8c01b7ec72d0e649
   file wims-monotone.texi in parent revision 
 21454253c9477ac8b44c9de7b46c21e69c34456c is wims-monotone.texi
   parent file identical, set copied all mapped and copy lineage
   merging lineage 
  from node 4684e0611ebc668312162c3d8c01b7ec72d0e649 
  to parent 21454253c9477ac8b44c9de7b46c21e69c34456c
   ../annotate.cc:455: invariant 'I(file_interned.size() == 
 other.file_interned.size())' violated
   saving current work set: 0 items
   
 
 Full debug file:
 
 
 
 Full version information
 
 
 monotone 0.23 (base revision: e32d161b8d5cde9f0968998cc332f82f82c27006)
 Running on: Darwin 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24 17:46:54 PDT 
 2005; root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh
 Changes since base revision: 
 new_manifest [68895899b164e1f443f988efef93e8384f1b182a]
 
 old_revision [e32d161b8d5cde9f0968998cc332f82f82c27006]
 old_manifest [68895899b164e1f443f988efef93e8384f1b182a]
 
 
 
 Wim Oudshoorn.
 ___
 Monotone-devel mailing list
 Monotone-devel@nongnu.org
 http://lists.nongnu.org/mailman/listinfo/monotone-devel


signature.asc
Description: This is a digitally signed message part
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel


[Monotone-devel] Re: Bug in annotate, renamed files?

2005-10-09 Thread Wim Oudshoorn
Emile Snyder [EMAIL PROTECTED] writes:

 Is this in a project that you could let me see, or proprietary code?  It
 would make it much easier to debug if I could do a pull of your project
 db.

Fortunaly this happens in one of my smaller databases.  I can give you 
access to my database, but I don't want it to be really public.  
So if you can send my your public key, I can give you access.

Wim Oudshoorn.



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