[Monotone-devel] Re: mtbrowser - Text based browser for source control
Nathaniel Smith wrote: On Thu, May 26, 2005 at 11:04:31PM +0200, Henry Nestler wrote: Nathaniel Smith wrote: I've checked it into mainline as contrib/mtbrowse.sh. Send me a key if you'd like push access so you can commit updates to it directly... Thanks, my pubkey attached. Cool. You should have push access now; I'll assume that you'll commit this new version directly. Have done it. Thanks. This will be a very nice test for update. I'm running in a coLinux session. The database stored and pull on host system (WinXP), connected with a fuse-lite filesystem, and working tree is in linux (checkout under Linux)... Commit dont't work on network mounted directories. See also BUG tracer https://savannah.nongnu.org/bugs/?func=detailitemitem_id=12455#comment1 Henry ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Regex for netsync branch selection
Netsync can now use regex matching against branch names. Cross-branch ancestor syncing also works now. Netsync commands can now take either a collection (like before) or a /regex/, both of which are converted to regex by the netsync code. (collection is escaped and has .* appended, /regex/ has the leading and trailing slashes removed.) The server limits access to the branches in the union of the collections/regexes given (and their ancestors). (Note that there isn't (and never way) a way to limit write access to only certain branches. I personally don't think the write-permissions hook should have a collection argument; that argument can't be enfored.) Old and new servers/clients can talk to eachother just fine, but if either is old regex matching won't work. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] and RFC: binary files merging and hook
Ok, I'll try to summarize the requests (and possible answers) so far: Both Nathaniel Smith and Emile Snyder advocated the use of .mt-attrs, perhaps coupled with the attr_init hook to automagically mark the files at add time. Howewer, the attr_init hooks receive only the filename, while the hook needs also the file content to guess the file type if the name doesn't matches. IMHO, the guessing part is a necessity, requiring the user to manually specify every binary file seem too harsh to me, especially because every project has its share of non mergeable files, even monotone ;-) The hook is here just to handle the corner cases (like file specific merging tools), but I think monotone should make the right choice automatically. Attributes seems also just not available at merge time. Both of these issues need to be resolved before using attributes to decide on merging. Is a rewrite of the attribute system needed ? Joel Crisp wrote: I'd prefer a 'file type' attribute rather than a binary file attribute - there are many types of files which may require specialist merging (e.g XML) or storage (e.g. super big video files which are stored external to the scm. The binary_file hook is used only to inhibit algorithmic merging (perhaps a better name for the hook would be disable_auto_merge). Essentially, a binary file is treated as a text file with a conflict, i.e. monotone will invoke the merge2 or merge3() lua hooks. The merge2/merge3 hooks receive both filenames and full file content, thus by redefining them you can use choose a specialized merge tool based on the file type (I made the example of gimp for merging images). AFAIK, monotone doesn't directly support storing files externally, but you can simulate it by storing only a pointer file and redefining the mentioned hooks. Glen Ditchfield wrote: You base the text/binary decision on the name of the file. How hard would it be to base it on the contents of the file instead, the way the Unix 'file' command does? The hook uses only the filespec, true, but if it returns nil, monotone will check the file content for ASCII NULs and some other control chars. Unless adding .mt-attrs support is more or less trivial, my proposal is to merge the current patch to resolve the merging bug. Then perhaps we could rethink a bit the attributes to have them available everywhere, not just when dealing with the working copy or the manifest. After that, adding a binary or disable_auto_merge attribute should be easy. What do you (collectively :-) think ? Riccardo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] newbie questions (best practices)
Hi, I've just started to use monotone and have some questions. 1. Should I maintain each project I'm working on in a seperate .db file? 2. If I do keep each project in a seperate .db, how do I share my work with my co-workers? Do I run `monotone serve myhost:port com.work.myproject` for each .db where, port is a unique number? Is there a way to have multiple .db's running on the same port? I just sync'd my database with a friend. I then updated my working copy. When running `monotone update`, monotone popped up `meld` to do a 3 way merge. I accidently, closed `meld` before doing the merge. As a result, it looks as if I've lost the changes I had made to my working copy. 3. Is there a way to get back the changes I made to my working copy? 4. If I had committed my working copy before sync'ing, what would have happened? Would I have been presented with the 3 way merge during the sync command? 5. If I had committed my working copy before updating, but after syncing, what would have happened? Would have been presented with the 3 way merge during the commit command? 6. Is there a general rule to follow when committing/updating/syncing, i.e. always commit before doing a sync or update? Thank you for any help you can provide. nathan ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] monotone.cvssync: Invariant failure
Hi all! I spend some time looking into my issue with cvssync today and have found out what is going on (I think). Seems like the gdb sources are using a module that is alias for a list of directories and files. cvs_pull fails on its face when it runs into the files, obviously it is assuming that a module is one (or maybe a few) directories. -- Gruss, Tobias Tobias Hunger The box said: 'Windows 95 or better' [EMAIL PROTECTED] So I installed Linux. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] movable monotone tags
On Fri, May 27, 2005 at 02:29:06PM +0300, Stanislav Karchebny wrote: On Thursday 26 May 2005 10:00, you wrote: Movable certs aren't really possible with the distributed nature of monotone. Basically, the old position of the tag might always came back and bite you. Yeah it can. Here's a little relevant bit of info i think from the git list Superceded tags http://marc.theaimsgroup.com/?l=gitm=111719320004462w=2 Eh, this is not really a problem; or at least, it's just the same problem you always have with parallel changes. (I.e., just like branches can have multiple heads, if you make tags versioned, they can have multiple heads too. Not very surprising.) AFAICT it's perfectly _possible_ to support versioned tags; you can think of each tag as being like a unique file, and its contents the revid that's being tagged -- then it's clear that if you know how to version files, you can come up with a way to version tags as well. Practically speaking, though, it's a big pain to add another type of object that can be versioned, teach all the code about it, teach netsync about it, and so on and so on. So I wouldn't expect to see this in monotone particularly soon... It does suggest another possibility for dealing with the original use case, where tags are used to tell an autobuilder what to build: you could instead have a branch that contains a file telling the autobuilder what to build, and the autobuilder checks out this file, looks at it, and does whatever. Dunno if this is better or worse than the other solutions suggested, but it's an option :-). -- Nathaniel -- Lull'd in the countless chambers of the brain, Our thoughts are link'd by many a hidden chain: Awake but one, and lo! what myriads rise! Each stamps its image as the other flies -- Ann Ward Radcliffe, The Mysteries of Udolpho ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
