Peripherally related to this, one thing I've noticed is that file and
directory renames are handled slightly differently vis-a-vis mtn mv.
If you start with the following file:
dir1/a.txt
And move a.txt to b.txt on the filesystem, and then issue mtn mv a.txt
b.txt (with or without
One thing that might be helpful for x86-based systems is to use a VM for
these buildbots. For instance, one person could set them up once inside
VMWare server (free) and then distribute the image to whomever was willing
to host one.
It would work for windows too, but OS licensing issues would
On 6/1/07, Markus Schiltknecht [EMAIL PROTECTED] wrote:
Basically, what I'm stating is, that the avg. history vs. checkout size
ratio probably is that low, because the tools to track history were
lacking. I bet that this ration will grow, as soon as people learn about
the benefits of properly
Also speaking as a user, it seems to me that the real use-case that drives
this feature is simply not transmitting ancient history in cases where the
user is unlikely to ever want it. The common use case consists of the the
guy who is not a monotone expert and wants to check out the head of a
The workaround is simple. The severity is low.
Call me shallow, but if I downloaded 0.32 for the first time in order to
evaluate monotone, this would probably cause me to put it back on the
shelf. Lack of versioned policy, performance, or other lack of
features probably would not.
That's not
Moving my .mtn-ignore did not fix the problem for me, unfortunately.
Even a 1-file/1-subdir test project consistently fails on my windows
machine.
RS
On 1/9/07, Thomas Keller [EMAIL PROTECTED] wrote:
Hi all!
Finally this bug gets more attention. I trap into it quite often with
0.32, using my
I'm using the pre-compiled windows binary.
RS
On 1/8/07, Rob Schoening [EMAIL PROTECTED] wrote:
This looks to be the same issue that I reported a week or two back.
For me, it is an invariant violation on line 308 of paths.cc. It seems to
be a regression in 0.32. The same paths work fine
I received a similar invariant failure (both assertions are in paths.cc, at
least) on Windows XP with 0.32, but with a 100% US character set. My
message post on the issue was rejected by the moderator for reasons unknown
(debug file was too big or something).
Here is the message that I sent
[EMAIL PROTECTED] wrote:
On Tuesday 02 January 2007 22:14, Rob Schoening wrote:
I received a similar invariant failure (both assertions are in paths.cc,
at
least) on Windows XP with 0.32, but with a 100% US character set. My
message post on the issue was rejected by the moderator for reasons
On windows I notice that that whole-workspace operations (ls unknown, ls
missing, commit, etc.) often take 10-20x longer when they have not been run
recently whereas a subsequnt execution (moments later) will return very
quickly.
Does monotone retain a cache someplace or is this performance
you can always use mtn log (or viewmtn) to look to see what is in your
repository, which is completely independent of your workspace. however
determining which revisions will be involved in a workspace update is a
little trickier.
To my knowledge there is neither a mtn update --dry-run nor a
One of the things that is missing in this discussion are real concrete
use-cases.
The main one that I have had to contend with is:
Assumption 1: VCS does no line ending conversion.
Assumption 2: Line endings in repository are all correct per the project's
conventions
Assumption 3: All editors
The current behavior is entirely consistent with what I would expect.
My goal is always to have mtn ls unknown to produce no output: a file in a
workspace should either be known or it should be ignored. But I can see
that in your case (where you're not tracking project source code), this
might
Here here.
RS
On 11/25/06, Ulf Ochsenfahrt [EMAIL PROTECTED] wrote:
Hi all,
This line ending thing is getting far too much attention, IMHO. My last
word on this issue is:
- Whatever I check in, I want checked out
- What I'd like to see is a setting where monotone checks on commit if
the
or is it hear hear ? ;-)
RS
On 11/25/06, Rob Schoening [EMAIL PROTECTED] wrote:
Here here.
RS
On 11/25/06, Ulf Ochsenfahrt [EMAIL PROTECTED] wrote:
Hi all,
This line ending thing is getting far too much attention, IMHO. My last
word on this issue is:
- Whatever I check in, I want
Keep in mind that when people used to using other VCSs ask about tags or labels, they may not understand that what they're asking for is already provided by monotone by way of the SHA1 revision id, albeit not with friendly user-defined names.
A common use-case is for development to tag a build
The new home page layout (get it, use it, improve it) is very thoughtful.
Kudos to whoever thought of that organization.
RS
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
for most professional software development projects. And that would be OK. ;-)
But it sounds like you have a pretty solid plan to aim higher than that. That is even better.
RS
On 9/15/06, Nathaniel Smith [EMAIL PROTECTED] wrote:
On Thu, Sep 14, 2006 at 03:17:32PM -0700, Rob Schoening wrote:I still think
I think the key point that I was trying to make and I seems that Koen was saying as well, was that the program doesn't suck and we're not really grumpy at all!
The roadmap that Nathaniel and others have presented in this thread seems entirely rational.
To my mind this is one of the better-run
Jumping back to the original idea being discussed...I would love to see this as part of the tool.
But does it take away from driving automate to a stable state? That is,would it make sense toimplement this as acommand-based wrapper first in order to help button down automate, and then fold it
This may be the strange behavior that I have seen with mtn mv in the past, particularly when using Eclipse's class/package name refactoringfor java sources.
After getting stuck a few times with invariant violations after moving directories and files into the new directories, I found that I could
When I was setting up ViewMTN last week (thanks to the helpfulposts with revisions/patches needed to work with 0.29) I noticed something unexpected.
When I ran mtn update -r to switch my workspace to a particular revision, it seemed to be sourcing one of the project files (mtn.py) and then
Does monotone have a concept of a project? I didn't think it did, other than by convention.
I'm not necessarily saying that it should, but since a lot of this use-case discussion revolves around authorization issues in the lifecycle of a project, it does beg the question somewhat.
Tim, how do
er...make that multi-tenant setup... ;-)
On 9/11/06, Rob Schoening [EMAIL PROTECTED] wrote:
Does monotone have a concept of a project? I didn't think it did, other than by convention.
I'm not necessarily saying that it should, but since a lot of this use-case discussion revolves around
That explains it.
RS
On 9/11/06, Nathaniel Smith [EMAIL PROTECTED] wrote:
On Mon, Sep 11, 2006 at 03:39:43PM -0700, Rob Schoening wrote:When I was setting up ViewMTN last week (thanks to the helpful posts with
revisions/patches needed to work with 0.29)I noticed somethingunexpected.When I ran
I went ahaed an added your answer to the Glossary on the wiki, Tim.
This question had been nagging at me for some time as well. ;-)
RS
On 9/8/06, Timothy Brownawell [EMAIL PROTECTED] wrote:
On Fri, 2006-09-08 at 16:18 +0200, Markus Schiltknecht wrote:
[EMAIL PROTECTED] wrote: Is there a
A suggestion to help prevent this from happening in the first place:
One feature that I've always wished for with CVS (and Monotone) is a slight bit more interactivity with the editor on commit.
Intuitively, I've always wanted to be able to exclude files from commit bysimply deleting
I will add that, as a user,I've been slightly mystified by .mtn-ignore myself.
I'm not aware of where the syntax is documented, but it seems to be different than .cvsignore. Maybe it uses regular expressions and not just simple wildcards.
Also, on several occasions I've found that a blank line
even without any tools, a one-page roadmapthat identifies upcoming releases and identifies features/fixesas targetingone release vs. another would be very nice. my guess is that this kind of basic plan would do more for adoption of monotone than most features would.
* no need to commit to
Is there a recommended way to roll a particular file or files back to a particular revision? mtn update affects the entire workspace, which I don't want. Obviously mtn cat -r revision foo.txt foo.txt
will work, but this seems wrong.
Is it? Or is there a better way?
RS
This is great!
FWIW, i find that the most useful feature of the SCM plugins is actually keeping track of renames.
Most VCS operations can be done outside the IDE fairly easily, albeit with a bit less style and ease of use. I find it more comfortable actually, but I'm probably in the minority
One thing that I have always found to be tremendously helpful with various VCS is having some kind of dry run command. With CVS, even something as pedestrian as cvs -nq update is tremendously helpful to test the depth of the waters before you dive in head first.
If there is such a feature in
as a user, my self-interest wants monotone to be stable and bulletproof above all else.
so if this issue distracts from that...
RS
On 6/13/06, Graydon Hoare [EMAIL PROTECTED] wrote:
Nathaniel Smith wrote: We all definitely agree that (0) is fine, and that (6) is not. Therefore, we probably each
The CC mvfs filesystem definitely gets points for being clever, especially being able to access arbitrary branches / versions using simple filename extensions.
But as you alluded to, it is too clever for its own good in a lot of ways.
Beware any VCS that needs to run in kernel mode!
The level
34 matches
Mail list logo
