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

[Grzegorz Jakacki]

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

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

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
Grzegorz