CooSoft Support supp...@coosoft.plus.com writes:
[...]
Git is far too complex in certain areas and it's easy to loose
stuff.
Too complex? In some sense, yes. The set of commands is rather random,
not consistent (it's obvious that much of it grew rather than being
designed). I disagree that
Hendrik Boom hend...@topoi.pooq.com writes:
On Tue, Dec 13, 2011 at 06:41:42PM +, Bruce Stephens wrote:
Make sure you've got something to offer. Back in the day there weren't
many practical DVCSs, but nowadays I'd guess that fossil would be a more
likely refuge for people who don't
CooSoft Support supp...@coosoft.plus.com writes:
Bruce Stephens wrote:
[...]
I was thinking about divergences from non-head revisions, in mtn you
just get two heads on the same branch. In git it goes off branch and
the only way you can get back to it is to remember the sha1 hash
Richard Levitte rich...@levitte.org writes:
[...]
Do we know for sure that all implementations of std::vectorchar work
in such a way that memcpy() and other functions with pure C semantics
will always work?
Yes (provided the elements are POD, anyway).
(Though using std::copy() would also be
Markus Wanner [EMAIL PROTECTED] writes:
[...]
The main motivation is making dates cert information more reliable. But
it looks like that's not considered core functionality of monotone.
I don't think anyone objects on principle. The question is just of
whether it's possible to do that in a
Markus Wanner [EMAIL PROTECTED] writes:
[...]
What surprised me about the pidgin repository is, that there are some
date certs with six digits (!) for milliseconds in the date, i.e.:
2006-11-01T21:39:36.807940
IIRC Tailor did that at one point, so likely that's a result of
converting from
Markus Wanner [EMAIL PROTECTED] writes:
[...]
Agreed. Thanks for pointing this out. I'll check if we can add dynamic
version checks as well.
http://www.sqlite.org/c3ref/libversion.html suggests it should be
easy enough.
___
Monotone-devel mailing
Markus Wanner [EMAIL PROTECTED] writes:
[...]
Any idea what CVS tags they define? I've checked out their CVS tree, but
I'm missing 'cvs ls tags' :-)
No idea. Choose a file that you expect to have been altered
frequently and do cvs log file. At the top will be any tags or
branch names.
Daniel Carrera [EMAIL PROTECTED] writes:
[...]
You point out that it is not consistent with git, but Bruce
explained that git is not consistent with anything. I've heard
elsewhere that git is not internally consistent either. So I'm not
sure that consistency with git should be a goal.
I
Daniel Carrera [EMAIL PROTECTED] writes:
[...]
So it can only happen if the developer has SSH access. Tell me if I'm
wrong, but if you want developers to tunnel through SSH they can then
execute Monotone commands including db execute. Right?
Indeed. So don't do that. Instead, offer a
Daniel Carrera [EMAIL PROTECTED] writes:
Is it possible to write a hook that implements Ludovic's solution to
the undo a commit problem? :
I don't think so, no. monotone's not designed to be extensible in
that sort of way. (Unless something radical has changed that I didn't
notice.)
You
Daniel Atallah [EMAIL PROTECTED] writes:
[...]
One thing that I haven't seen mentioned in these conversations about
kill_rev_locally (perhaps I glossed over it) is someone explicitly
noting that if the revision in question has already been pushed to
another DB, a pull from that DB will
Ludovic Brenta [EMAIL PROTECTED] writes:
[...]
I would prefer a single-purpose command, mtn rebase -r rev, that only
rewrites the old_revision field in _MTN/revision. Then, the user can
either kill_rev_locally h:, disapprove h:, or simply commit to create a
divergence if that's what they
Daniel Carrera [EMAIL PROTECTED] writes:
Daniel Carrera wrote:
Ok. mtn suspend and mtn disapprove look like good
solutions. Combined with mtn rebase that would cover my use case.
Actually, it looks like suspend is used to suspend certs rather than
revisions. But that's ok, I still have
Daniel Carrera [EMAIL PROTECTED] writes:
[...]
If you get a standard hosting package to use as a central server,
the web host is not going to let you run a separate server program
on a new port. So if you are a Windows developer and your server is
a typical web hosting package, you can't use
Daniel Carrera [EMAIL PROTECTED] writes:
Bruce Stephens wrote:
I'd have thought a typical web host wouldn't let you install programs
at all, so the ssh option would also fail (since it requires that you
be able to run monotone on the remote host, albeit through ssh)?
I figured I could just
Daniel Carrera [EMAIL PROTECTED] writes:
How do I undo a commit? I just made a commit and I just realized that
the commit included a file that I did not want committed in this
patch. What's the command to undo the last commit call? Is
disapprove the right command? It looks like the closest
Daniel Carrera [EMAIL PROTECTED] writes:
Lapo Luchini wrote:
Alex Sandro Queiroz e Silva wrote:
It looks like the closest thing, except that it keeps a
history off the change and the undoing of the change. Is that right? Is
that a feature?
Yup, it's because it's monotonic in nature you can
Daniel Carrera [EMAIL PROTECTED] writes:
[...]
Yeah, I was just reading up on those three (I already know Darcs and
it doesn't use signatures). A lot of people say that Git is
complicated and poorly documented, so I'm ignoring Git. Mercurial and
Bzr both look easy to use, but like you say,
Lapo Luchini [EMAIL PROTECTED] writes:
Bruce Stephens wrote:
Yup, it's because it's monotonic in nature you can only add, never
remove.
Does that have anything to do with why Monotone is called Monotone?
No, not really.
The original idea (IIRC) was that monotone update would always
Daniel Carrera [EMAIL PROTECTED] writes:
[...]
So I am still at the a4042.. revision. And in the log I can see that
it mentions the file that I did not want to include in this commit.
Help?
I think disapprove *only* changes the database. You need to do mtn
update to change your workspace.
Daniel Carrera [EMAIL PROTECTED] writes:
[...]
In which way are signatures more pervasive in monotone?
Every cert is signed.
(In that case it's not much different from
monotone; in monotone revisions aren't signed, rather the things
attached to revisions get signed, so if you have a tag,
Bruce Stephens [EMAIL PROTECTED] writes:
Lapo Luchini [EMAIL PROTECTED] writes:
[...]
Uh, really? 0_o
I had thought for the past years that monotone meant just that…
Yes, I think it was about monotonically non-decreasing quality, not
about never removing stuff.
I was fairly sure
Daniel Carrera [EMAIL PROTECTED] writes:
[...]
So Monotone is expecting me to figure out which files it is not
tracking and remove those files before it'll update the working
directory?
Yes, when the update is trying to remove a directory containing such
files.
I can't have files or
Daniel Carrera [EMAIL PROTECTED] writes:
Bruce Stephens wrote:
[...]
mtn commit always adds four certs (author, date, branch, changelog).
The revision itself is not signed, but those four things are (and they
reference the revision).
Ok. But the signature also covers the SHA1 sum
Daniel Carrera [EMAIL PROTECTED] writes:
[...]
My current solution is Darcs, which indeed makes the above easy. When
I run darcs record, darcs shows me the changes one at a time, and I
can tell it which ones to include in the patch. Another equally good
solution is: (1) record the current
Derek Scherger [EMAIL PROTECTED] writes:
Even if size does have to traverse a list to count the elements one would
expect that traversing an *empty* list should be reasonably quick.
Sure, but presumably the extra cost is traversing a non-empty list to
find that it's not empty. One would hope
Ulf Ochsenfahrt [EMAIL PROTECTED] writes:
[...]
If there is an invalid pointer in the non-empty list, the program
can crash.
It can crash, but this is presumably in the realm of undefined
behaviour, so arbitrary things are permitted to happen.
If the compiler optimizes (i.e. removes) the
Ulf Ochsenfahrt [EMAIL PROTECTED] writes:
[...]
What about inifinite loops? The linked list could also loop back to itself.
Is there any guarantee that a std::list is a linked list? Is it
possible to produce a cycle in a std::list? Is the behaviour of
size() on such a list defined?
[...]
Lapo Luchini [EMAIL PROTECTED] writes:
Zack Weinberg wrote:
[...]
The manual is out of date. Database storage is binary, 8-bit clean,
Wow, how old is that?
I began using mtn a good couple of years ago, and all I remember about
storage (I don't remember where I read it) is that I was
Stephen Leake [EMAIL PROTECTED] writes:
[...]
The Makefile runs 'texi2dvi --pdf --batch monotone.texi' to generate
the pdf; you might try playing with other options to see what happens.
That seems unlikely to help in any easy way. A possibility might be
to try the DocBook path, and maybe
Brian May [EMAIL PROTECTED] writes:
[...]
This single feature [rebase] of git has produced huge (and heated)
controversy on the debian-devel (and probably other) mailing
list. It seems everyone has a different idea of when re-basing is
required, and when it should or should not be used.
Matthew Nicholson [EMAIL PROTECTED] writes:
[...]
I like the idea of local branch namespaces. How do they implement it?
Just use like the sha1 hash of various things as the true branch name
and then map that to a texual name locally?
No. commits don't contain any branch information.
William Uther [EMAIL PROTECTED] writes:
[...]
- Git only downloads one branch (and has some support for partial
checkouts)
That's not true (the first part, the second is true).
I imagine the confusion happens because if you do git clone ...,
then in that checkout git branch shows
William Uther [EMAIL PROTECTED] writes:
[...]
* Merging:
- Monotone uses mark-merge and 3-way text merge
- Monotone stores more information (which files moved when)
- git uses heuristic merging
- Git never gets stymied by something outside its model (e.g.
die-die-die
Patrick Georgi [EMAIL PROTECTED] writes:
[...]
Basically mtn-plucking a set of revisions to somewhere else, while
giving the head of somewhere else a suspend cert. That will make the
repository grow a lot, of course (as we don't throw away things)...
Shouldn't be a lot, since typically there
Patrick Georgi [EMAIL PROTECTED] writes:
Am Sun, 4 May 2008 08:18:25 + (UTC)
schrieb Holger Freyther [EMAIL PROTECTED]:
- git-rev-list origin/qtwebkit.. (to show what I would push now)
is missing
What's origin - the last server you connected, or the default one?
origin is (usually)
Thomas Keller [EMAIL PROTECTED] writes:
[...]
Oh, I'm sure we're all quite happy to accept your patches, detailed
bug reports and are of course willing to look over any feature
branches you may have been prepared!
AFAIK there's no reason to believe that the people complaining have
any
Patrick Georgi [EMAIL PROTECTED] writes:
[...]
I'd have thought note_netsync_revision_received or something would be
OK for that? Maybe one wants a hook that receives all the revisions
in one go or something?
hmm.. initialize a branch list at the beginning, then check each
incoming
Justin Patrin [EMAIL PROTECTED] writes:
[...]
It looks like the original discussion is here:
http://projects.linuxtogo.org/pipermail/openembedded-devel/2008-March/004642.html
I haven't been reading my mail very carefully lately.
The majority of complaints seem to be that merge is broken. I
Holger Freyther [EMAIL PROTECTED] writes:
[...]
Seriously I'm impressed what you have achieved with mtn, I like most of it,
but
in terms of improving the way I develop mtn is getting in my way more and more
often (and it is not the speed).
I agree with you (I'm finding git fits much better
Justin Patrin [EMAIL PROTECTED] writes:
It seems that some of the folks at OpenEmbedded are now grumbling
about use of monotone again and that some of our key developers are
looking to switch to something else (hg or git)[1]. The main point
of contention seems to revolve around, as we've seem
Julio M. Merino Vidal [EMAIL PROTECTED] writes:
[...]
Even with policy branches, will that be possible? Tag certs, at the
moment, cannot be identified by anything else other than their
contents itself; i.e. they do not have an author nor date attached to
them. So, how can you ban a tag
Jack Lloyd [EMAIL PROTECTED] writes:
Is this not possible? I had a feeling it wasn't, and the manual
suggests the same. Can add an alternative tag easily, of course, but
as soon as a tag escapes 'into the wild' it is out there forever,
yes?
Yes. Unless you can persuade everyone to delete it
Stephen Leake [EMAIL PROTECTED] writes:
[...]
My question is; can we just tell monotone to ignore this?
IIRC when I built monotone on HP-UX (at the time it didn't have the
/dev/[u]random patch installed) it required a change to the botan
source. Straightforward enough, but not just
Markus Schiltknecht [EMAIL PROTECTED] writes:
Oh.. that makes me wonder how hg and git handle non-content conflicts.
In git, file/file conflicts (where you add distinct files with the
same name on two branches and merge) are just content conflicts.
About the only kind of non-content conflict
Bruce Stephens [EMAIL PROTECTED] writes:
Markus Schiltknecht [EMAIL PROTECTED] writes:
Oh.. that makes me wonder how hg and git handle non-content conflicts.
In git, file/file conflicts (where you add distinct files with the
same name on two branches and merge) are just content conflicts
Nuno Lucas [EMAIL PROTECTED] writes:
On Feb 9, 2008 11:47 AM, Bruce Stephens [EMAIL PROTECTED] wrote:
[...]
git bisect has no connection to cherry-picking, as far as I know. git
bisect is just a scripted way to do git checkout for a sequence of
revisions.
I stand corrected. One shouldn't
Nuno Lucas [EMAIL PROTECTED] writes:
[...]
An extreme example of cherry picking is git bissect command. You
could have the some functionality on monotone if people could also
unpluck a changeset.
git bisect has no connection to cherry-picking, as far as I know. git
bisect is just a scripted
Markus Schiltknecht [EMAIL PROTECTED] writes:
[...]
I'd generally vote for files, even if that's still a long way to go.
That strikes me as impractical. How can I merge two revisions if I
can't see some of the changed files? If my local repository contains
the files, how convincing is it
Markus Schiltknecht [EMAIL PROTECTED] writes:
Bruce Stephens wrote:
That strikes me as impractical. How can I merge two revisions if I
can't see some of the changed files?
You should be able to merge, as long as the revisions you are trying
to merge both point to the same revid for all
Markus Schiltknecht [EMAIL PROTECTED] writes:
Bruce Stephens wrote:
Hmm. So the manifest has a hash that points to something that says I
don't have permission to it (rather than to the text itself). I guess
I can imagine that working.
Uh.. the manifest has never included the text itself
Markus Schiltknecht [EMAIL PROTECTED] writes:
Bruce Stephens wrote:
Uh.. the manifest has never included the text itself, AFAIR. And still
today, the revision data references the file's contents by hash
exclusively. So do the rosters.
I know, I meant that the thing referenced by the hash
[EMAIL PROTECTED] writes:
[...]
What complications does it have?
The tags are in-band (the .hgtags file), so creating a tag creates a new
revision.
Also, the algorithm mercurial uses to determine the version of the .hgtags
file
is not transparent.
It was the latter I was thinking
Pablo Delgado [EMAIL PROTECTED] writes:
Recently I gave the instruction to my developers to tag a certain
revision with a DTS-1.4 tag.
Shortly after, they realized they did not commit the final changes
that belonged to the release.
So they commited the recent changes and then tagged the new
Thomas Moschny [EMAIL PROTECTED] writes:
[...]
We also should have a look at what other VCSs do here - does
e.g. git discriminate between author and signer?
Signing is much less significant in git.
Having one person commit something that someone else authored is
routine (it's the way that
Julio M. Merino Vidal [EMAIL PROTECTED] writes:
On Jan 29, 2008, at 12:22 PM, Bruce Stephens wrote:
[...]
Having one person commit something that someone else authored is
routine (it's the way that most public git projects operate), and yes,
git distinguishes committer and author
Thomas Moschny [EMAIL PROTECTED] writes:
On Monday 28 January 2008, Graydon Hoare wrote:
[...]
The changes are, primarily: [...]
- a sketch of the long-planned upgrade to certificates
Can you explain that a bit? Is this related to the idea of creating
combined certs consisting of a
Thomas Moschny [EMAIL PROTECTED] writes:
[...]
This would leave us with currently four pre-defined cert types: 'commit'
resp. 'commit-message', 'branch', 'tag' and 'suspend'.
And test-result.
Maybe that one needn't be predefined, though.
___
Thomas Moschny [EMAIL PROTECTED] writes:
Markus Schiltknecht wrote:
[...]
Instead of trying to merge those certs together, I'd rather try to
increase locality of those certs in the database as well as during
netsync. That way, all certs would benefit, instead of only those which
might
Ralf S. Engelschall [EMAIL PROTECTED] writes:
[...]
But what if change1 and change2 overlap in a file, say file11 == file21.
My solution since many many years (there just with cvs and svn, now
with mtn) is:
Have you tried qct? Presumably other similar tools provide similar
functionality.
I
Lapo Luchini [EMAIL PROTECTED] writes:
[...]
Of course, those are problems that can (and probably should) be solved
by a GUI with colored diff and a mouse interface to click to deselect
chunks or something like that ;-)
That's the kind of thing git-gui offers, yes.
But well... not strictly
Craig L. Ching [EMAIL PROTECTED] writes:
[...]
Well, that brings up an interesting question. So would it also be
possible for a revision to have two author certs as well?
It can have any number of any certs, yes.
Ordinarily that's not common, but it's not unusual for merges to end
up with
Bruce Stephens [EMAIL PROTECTED] writes:
[...]
Ordinarily that's not common, but it's not unusual for merges to end
up with two copies of the normal certs (author, date, branch,
changelog), with the branch and changelog the same (automatically
generated, and signed by the two author keys
Craig L. Ching [EMAIL PROTECTED] writes:
Heh, I figured that but thought I'd just make sure, sometimes things
aren't as obvious as they seem, not so in this case ;-)
There may be more than one of any kind of cert, and in each case it
means what it logically ought to.
(Automated merging often
It just means it's on two branches.
(Presuming that you trust both certs: see get_revision_cert_trust.
[Insert standard comment about policy branches].)
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
Craig L. Ching [EMAIL PROTECTED] writes:
[...]
Ok, something I didn't mention is that mtn automate select
[EMAIL PROTECTED] returns revisions. This confused me, so I looked
into it further and indeed there is another cert with
[EMAIL PROTECTED] as the key. So, you have two keys apparently?
Craig L. Ching [EMAIL PROTECTED] writes:
Yes, my apologies, that's what I meant, two certs with different
author values for the same key.
No need to apologise. While it's all quite logical there's certainly
opportunity for confusion.
[...]
___
Jack Lloyd [EMAIL PROTECTED] writes:
I don't understand how to do limited write permissions (eg, to allow
a particular key write access on one specific branch).
You can't. Once the branch certs are in the repository, you can
choose not to use them. But you can't stop them getting there (if
Jack Lloyd [EMAIL PROTECTED] writes:
On Wed, Oct 24, 2007 at 04:26:46PM +0100, Bruce Stephens wrote:
Jack Lloyd [EMAIL PROTECTED] writes:
[...]
You can't. Once the branch certs are in the repository, you can
choose not to use them. But you can't stop them getting there (if
you permit
[EMAIL PROTECTED] writes:
[...]
I vote[0] for the new Botan, perl dependency and all.
What does vote[0] mean?
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Chad Walstrom [EMAIL PROTECTED] writes:
[...]
Would there be a way to tell sqlite to ignore indices for given
operations, such as pulls?
That strikes me as a low-level question that should be ignored (at
least unless it causes some measurable problem).
One would hope that SQLite will only
Markus Schiltknecht [EMAIL PROTECTED] writes:
[...]
Maybe cvs2svn is coming closer to being able to export to monotone.
I don't think there's any question. There's (experimental,
admittedly) code to export to git, and it's ~500 lines of Python.
git is more or less equivalent to monotone in
Patrick Georgi [EMAIL PROTECTED] writes:
Bruce Stephens schrieb:
[...]
For that matter, I guess it might be feasible to read git's
fast-import format instead (that would probably take a bit more
effort, but might be more useful).
I started such an effort, but considered it not worth
Anthony Edward Cooper [EMAIL PROTECTED] writes:
[...]
Am I correct in assuming that the either one party or both involved
with the sync exchange checks the data being received/sent. Say by
rechecking the hashes on all data transferred?
And the signatures of all the certs, yes. The
Michael Haggerty [EMAIL PROTECTED] writes:
[...]
(I've already made this offer [to cooperate in adding mtn support to
cvs2svn] to Markus Schiltknecht but he doesn't seem interested.)
I suspect because cvs2svn isn't incremental. So it's a way to do a
one-time conversion of a CVS repository,
Michael Haggerty [EMAIL PROTECTED] writes:
[...]
cvs2svn added the unnecessary branch names because of a bug in
git-fast-import. I think that problem is fixed, but I haven't gotten
around to changing cvs2svn.
Ah, OK.
More interesting is whether the branches have to be created at all
for
Patrick Georgi [EMAIL PROTECTED] writes:
[...]
There are a couple of invariants in the code that require revisions
to only have to ancestors. And I think some of the routines are
hardcoded for either one or two ancestors, too.
OK, I was misremembering.
Markus Schiltknecht [EMAIL PROTECTED] writes:
[...]
Right. For every tag and branchpoint which cannot be matched to
exactly only one revision, you'll have to add an artificial revisions
which you can tag. (AFAICT, git allows such an artificial revision to
have multiple parents, monotone does
Nathaniel Smith [EMAIL PROTECTED] writes:
[...]
If you're interested in making something like this work, I'd suggest
looking at
http://article.gmane.org/gmane.comp.version-control.monotone.devel/12022
and also git's 'git-submodule' command for an existing and deployed
implementation of
Julio M. Merino Vidal [EMAIL PROTECTED] writes:
[...]
OR simply build monotone 0.36 yourself and install it in /usr/local.
No need to switch the whole system to unstable to get a more recent
version of a single package, specially if it is a tool that nothing
else relies on.
For those of us
Stefan Monnier [EMAIL PROTECTED] writes:
[...]
Also, there are plans to update VC to be a bit friendlier by making VC-dired
work better.
So, in any case, Emacs-22.2 will have VC backends for Git, Bazaar, and
Mercury, and it would make sense to add Monotone to the list.
Indeed, and that's
Graydon Hoare [EMAIL PROTECTED] writes:
Bruce Stephens wrote:
Right, so this is the same idea as nested checkouts, but using the
manifest rather than some other mechanism?
[...] Would have been easier if we'd designed it into the first
pass, but we drew the line of what to implement a bit
Julio M. Merino Vidal [EMAIL PROTECTED] writes:
On 06/08/2007, at 18:03, Bruce Stephens wrote:
[...]
I suppose monotone could warn (or give a conflict) if, when merging, a
file has been modified in one branch and dropped in another, on the
grounds that the modifications might be significant
Robert White [EMAIL PROTECTED] writes:
[...]
But if you decompose the way modules really work in CVS and abstract
that to the manifest system there is a way to do it. Essentially you
need to consider that when you checkout a complicated directory tree
where sub-trees are deferred into other
William Uther [EMAIL PROTECTED] writes:
[...]
Did you ever commit your version to a branch?
I had it in a local repository, but I'm fairly sure it's lost by now.
This was before the rosters change, IIRC, and I suspect I just blew
away the old repositories.
The change was fairly
William Uther [EMAIL PROTECTED] writes:
[...]
Ahh, yes. I remember that now. Is there a reason why it isn't
linked from the monotone front page? (There is a link titled
Savanah, but not bugs) Is it too out of date to be useful?
bugs / todo list points to the savannah bug tracker.
William Uther [EMAIL PROTECTED] writes:
[...]
Anyway, I have another proposed solution. It is a 'suspend' cert.
It looks the same as a 'branch' cert in that it contains the name of
a branch. The effect of a 'suspend' cert is to remove that revision
from any list of heads for that
Joel Crisp [EMAIL PROTECTED] writes:
Interesting, but how would you ensure that all distributed nodes had
the same version of the command scripts?
Policy branches?
Having different nodes with different collections of extra commands is
surely an issue, but it's not one that seems to bother
Ludovic Brenta [EMAIL PROTECTED] writes:
I experimented with importing a project into Monotone using tailor.
This worked well, but the timestamps for most revisions contain
microseconds, like this: 2007-06-27T08:58:38.950999.
Indeed. In case anyone's worried, that's been fixed in Tailor now.
Anthony Williams [EMAIL PROTECTED] writes:
[...]
I tried using merge_into_dir to add the shared_project files as a subdir of
project1, which sort-of works, but now I have to remember to pluck the changes
back to the shared_project branch. Also, if I add a file in
project1/shared_project and
Nathaniel Smith [EMAIL PROTECTED] writes:
[...]
Eek, we should fix that. (And 0.6s vs. 3.5s is the difference between
instant and twiddle-twiddle-twiddle in user experience terms.)
We have no excuse for going 6 times slower on status; we should be
(and at some point were) fast-pathing
Brian May [EMAIL PROTECTED] writes:
[...]
As there any references on how policy branches will solve these
problems?
No. It hasn't been designed yet. There are some candidate ideas on
the wiki.
Some bits are easy: for internal purposes, branches are an identifier
(probably a hash), and the
Graydon Hoare [EMAIL PROTECTED] writes:
Thomas Moschny wrote:
Having combined certs would solve that problem at the cost of
sometimes storing the same information twice: e.g. when two people
do the same merge, there will be two certs with different
dates/authors, but identical branch names
Derek Scherger [EMAIL PROTECTED] writes:
[...]
The ui/command-set in git seems complicated and somewhat strange though.
For example the fact that pull does fetch+merge seems a bit odd coming
from monotone. It almost seems like fetch should have been called
pull and merge could have been
Brian May [EMAIL PROTECTED] writes:
J == J Decker J writes:
J Harsh (also beware of falling rants) Unforutnatly,
J although monotone has become much much better for performance
J issues... it was knocked out of the world of 'valid'
J distributed version control systems
Markus Schiltknecht [EMAIL PROTECTED] writes:
[...]
Monotone even has the concept of a project, which groups together
multiple branches.
Does it?
[...]
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
Nathaniel Smith [EMAIL PROTECTED] writes:
[...]
Oh, I know: how about an 'annotate diff' combination command, that
shows a unidiff, but also marks each + and - line with the person
responsible for that change?
Doesn't help if you are looking at a file and wondering generally
how it came to
Bruce Stephens [EMAIL PROTECTED] writes:
[...]
Hmm, mostly by messing about, how about the attached? (Testing
involves
OK, that fails in more complex situations.
I attach a patch with a test (the test fails with the trunk, but
succeeds with the change to diff_patch.cc) which seems to work
Bruce Stephens [EMAIL PROTECTED] writes:
[...]
I attach a patch with a test (the test fails with the trunk, but
succeeds with the change to diff_patch.cc) which seems to work, but it
seems ugly. It's not obviously right, anyway.
Ah, the new test passes, but the previous one
1 - 100 of 391 matches
Mail list logo
