monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] New project: libmtn


From: Arseny Nasokin
Subject: Re: [Monotone-devel] New project: libmtn
Date: Tue, 4 Jul 2006 17:50:56 +0400
User-agent: mutt-ng/devel-r581 (FreeBSD)

On Fri, Jun 30, 2006 at 10:47:15PM -0700, Justin Patrin wrote:
> On 6/30/06, Nathaniel Smith <address@hidden> wrote:
> >On Fri, Jun 30, 2006 at 05:44:25PM +0400, Arseny Nasokin wrote:
> >> - revisions can be complex (why it? why not per-action?), _so_ can't be 
> >> disapproved. split revisions?
> >
> >You still have not said what you mean by "complex", so I can't
> >really comment on this.
> >
> 
> Aha! I think the OP means that you check in changes to multiple files
> in one revision. i.e. multiple "patches" as he puts it and multiple
> renamed, adds, deletes, etc.
> 
> The answer is that of course monotone doesn't split up each "action"
> into its own revision. This is one of the points of a revision based
> system instead of a file-based one (such as CVS). When you make
> related changes to a list of files they should be checked in as one
> logical revision, not a sequence of unrelated changes to various
> files.
> 
> OP: If you want to separate the "actions" in one revision, choose
> which files you want to commit. I routinely make many changes in one
> workspace and then commit parts of it individually to keep the changes
> as separate revisions. I still check in changes to multiple files at
> once, but in sections so that only directly related changes are in
> each revision.
> 

Yes, I know it, but I can't edit revision at that case: I must create backward 
mtn-diff for several files and  create new revision :(
And for added/dropped files I should disapprove all and commit it again. It's 
too mad when time is critical 
-- 
   Best regards,
        Arseny Nasokin




reply via email to

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