monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: New project: libmtn


From: Bruce Stephens
Subject: [Monotone-devel] Re: New project: libmtn
Date: Sun, 02 Jul 2006 22:34:32 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Joel Rosdahl <address@hidden> writes:

[...]

> 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.

Sure, and subversion doesn't at present even record merge information.
So my example wasn't very good.

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

Imagine that rather than merging, you copied.  So you do:

        svn cp <url>/cvs2svn/trunk <url>/cvs2svn/branches/1.4.x

That *is* recorded.  Then, some time later, you do

        svn cp <url>/cvs2svn/trunk/cvs2svn.1 
<url>/cvs2svn/branches/1.4.x/cvs2svn.1

That's also recorded.  Or you could do

        svn cp <url>/cvs2svn/branches/1.3.x/cvs2svn.1 
<url>/cvs2svn/branches/1.4.x/cvs2svn.1

And you can do that not just for individual files, but for directories
too.  The history of things, including where they came from, is
per-file.

It's not (in general) possible to draw a graph such as monotone-viz
does, for example: the set of files corresponding to a typical
workspace need not have a common history.




reply via email to

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