[Top][All Lists]

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

Re: [Monotone-devel] Re: Commit without working copy

From: Grzegorz Jakacki
Subject: Re: [Monotone-devel] Re: Commit without working copy
Date: Sat, 04 Dec 2004 11:27:10 +0800
User-agent: Mozilla Thunderbird 0.9 (X11/20041103)

Bruce Stephens wrote:
Grzegorz Jakacki <address@hidden> writes:


What about POST part? I have a content, filename (but not file) and
SHA1. How do I feed these into a repo?

You can't, at present.

OK, thanks. Where should I look into the code if I want to add it?

It's asymmetric: it makes perfect sense to get
a file, once you've specified it sufficiently, but it doesn't make
sense to store the contents of a file without specifying enough

I don't get it. AFAIU I am providing enough context. Why do you think otherwise?

Storing would make sense for a database, but not for the
kind of version control system that monotone is.

I don't get your point. What does it mean that "storing would make sense for a database, but not for [this] kind of version control system" ?

If you serialised write access, I suspect you could make something
that made sense: so storing a file given a branch, filename, and file
contents, would add a revision on the head of that branch.

I will show you a scenario, you tell me why you think it does not make sense.

(1)  There is a repo that has only one file. Repo database location
     is global and known.
(1)  You check out a tree into a local copy.
(2)  You write down:
       SHA1 of manifest
       SHA1 of the only file
       name of the only file
       content of the only file
(3)  You remove working copy.
(4)  You recreate working copy based on notes you
     have taken in item (2). You modify the file content.
(5)  You commit.

Now, is the context you have written down sufficient to commit reasonably? Yes IMHO.

Imagine now, that instead of writting down and recreating from notes, you send data to and from web client. What does not make sense?

As for serializing access: why do I need it? Isn't database backend taking care of it?

But you'd
need to make sure that you could never get more than one head to the

Why? Seems like you are making assumptions for me. If multiple users commit multiple heads, I am OK with it. The GET request will just show many revisions (or one arbitrary revision plus information that this branch is not merged).

Or, instead of providing a branch, you could provide the hash of the
revision (the one that the original copy of the file came from).  Then
you'd want some way to invoke merge and deal with possible conflicts,
and that might be challenging in a wiki.

If there is anything that system can merge without intervention, it will do. All other multiple heads are left for users to resolve. I don't have a problem with it.

If you could resolve the conflict problem, then the rest seems to me
to make sense: when you get the file contents, you remember the
revision from which it came, and you provide that when you store the
modified version.

Where should I look if I want to add the commit-without-working-copy functionality?

Thanks for all comments

reply via email to

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