monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Re: New project: libmtn


From: Joel Rosdahl
Subject: Re: [Monotone-devel] Re: New project: libmtn
Date: Sun, 02 Jul 2006 22:21:09 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.18 (linux)

Bruce Stephens <address@hidden> writes:

> Joel Rosdahl <address@hidden> writes:
>
> [...]
>> AFAICT, that is incorrect. Subversion has had whole-tree commits
>> from day one, so it also has the same problem.
>
> You're mistaken.

OK. Maybe I haven't understood the Subversion model in enough detail.

> A subversion repository has a revision number, and each change to
> the repository (which may involve changes to many files) increments
> the revision number.

Yes.

> [...]
> If that's all you do, then the branch is just as in any system
> (excepting CVS).

Agreed. Well, maybe except that there are other file-centered systems
besides CVS (ClearCase, for instance).

> However, you might decide that the branch would be better with an
> updated manpage, so you can update that one file (in a variety of
> ways). I guess you'd do something like this:
>
>         svn co <url>/cvs2svn/branches/1.4.x cvs2svn-branch
>         cd cvs2svn-branch
>         svn merge <url>/cvs2svn/branches/1.4.x/cvs2svn.1 
> <url>/cvs2svn/trunk/cvs2svn.1
>         # check file, then commit

Yes.

> Similarly you could update a directory, or every file whose name
> contains a 'q'. And next week you could make some other similar
> change.

I fail to see how other systems differ in this case, except for UI.
The man-page update (assuming no renames or copies, etc), for example,
roughly translates to this in Monotone:

    mtn co -b cvs2svn/branches/1.4.x cvs2svn-branch
    mtn co -b cvs2svn/trunk cvs2svn-trunk
    cd cvs2svn-trunk
    diff -u cvs2svn.1 ../cvs2svn-trunk/cvs2svn.1 | patch -p0
    # check file, then commit

In Monotone, as well as Subversion, you can make whatever changes you
want to your working copy and then commit. In Subversion, the merge
command is just a way of making changes to the working copy.

If you take recording of merge information into account, the situation
is of course different, but since this discussion is in the context of
conversion from CVS, merge information should be irrelevant.

So, I'm probably missing something. I don't understand what you mean
by "subversion [...] also does things for each file separately".

Regards,
Joel

-- 
Joel Rosdahl <address@hidden>
Key BB845E97; fingerprint 9F4B D780 6EF4 5700 778D  8B22 0064 F9FF BB84 5E97




reply via email to

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