[Top][All Lists]
[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