thank

you you haven't even heard what I have

to say yet um okay so since we're a nice

cozy audience I mean the material I've

prepared is introductory um mostly

anyway so to the idea is to give a

flavor of what darks is about why it

exists um how it works at at a fairly

high level um but I do know that at

least a third of the audience is quite

familiar with darks and I don't know

about the rest of the audience but I'm

happy to sort of you know dive into more

details in terms of questions and so

forth if if people would like that um so

um yeah so in when I get to the demo for

example if everybody feels that they

know exactly what dark stars and so

forth I can skip that and um instead you

can ask difficult questions about some

of the other

slides um so I guess does does anybody

not know what darks

is has anybody here not used

dos okay so then at least some

introductory material is

worthwhile um

sorry that one right okay so what is um

so I guess from a point of view of um a

Haso programmer you probably only come

across dark you may I mean these days

you probably only come across darks

occasionally um a lot you know five

years ago most high school projects were

um were in dark were hosted in darks and

now roughly speaking get as one and um

there are only a few hard projects that

are still using darks

um so what is it exactly well I mean in

like get material and so forth it is

it's a distributed version control

system and historically it was one of

the very early ones to be around um

after T and what's now Arch and um

things in some ancient stuff in that

mold um so in other words it's

distributed it's not like subversion in

CVS it doesn't have one Central server

or at least you're not forced to have

one Central server but I think the

concept of distributed version control

is now pretty familiar to people um

unlike other distributed systems or in

fact any other version control system um

the first class objects in darks are

patches um so in most Version Control

Systems what you try to do what really

what the Version Control System cares

about is storing trees of um your Source

tree and you change it a bit and it

stores another copy of your Source tree

probably with a lot of sharing and um

optimization so that it's not it's not

storing an entire copy each time um but

as far as the version control system is

concerned its job really is just to give

you back uh Source tree at a particular

revision um and keep track of all that

for you um darks tries to in its sort of

fundamental model keep um use patches um

so the changes between trees rather than

the actual trees themselves and I'll go

into more about that

later um so why bother um and by the way

I just add that it is I'm very happy to

have heckling from G users who think

that g is the be all and end all we can

have a nice argument

um so but why bother keeping darks going

um I mean we could basically stop say to

tell everybody who's using darks you

might as well stop you might as well

switch to GitHub right now um so those

of us who are still working on it think

that it does actually this this idea of

using first class patches is actually

important it does actually give you a

kind of power um and a different a

different kind of model for working with

um working with Version Control that

makes um that that really does give you

some something that get and mural and so

forth don't give you

um and the other way of the other aspect

of this is that I mean in practice most

projects are are hosted in git nowadays

and we need um we're working on uh on

having a bridge to get so that you know

people will be able to say host their

projects and get and um some people are

able to use darks or some people might

have their Central host be in darks and

allow people to submit git patches um so

that's kind of in progress but um you

mention gives the impression of being

based on

in what way does it I

mean well no what you what you see um

what you see in the git user interface

is are commits right so there are and so

those are that's that's a specific

specific state of a repository right so

if you know if you say bring up if you

bring up the git user interface and you

look at you will see a tree of um or

graph really of of revisions and each of

those revisions will correspond to a

specific sourc tree um so whereas in

darks when you look at the changes in a

repository each of those changes really

does correspond to the changes from the

previous date and that's that's how dark

stores them and that's how darks lets

you manipulate them that that would be

my I'm sure you know what I mean really

here but um that that would be my Spiel

for that that

question okay um so what what does it

really mean to have first class patches

um well I guess part of part of this is

really just is is really just a

philosophical difference I

mean hasal has first class functions so

does c right um but it's it's fairly

clear which you'd prefer to use if you

actually if you really want to write

functional programs um and that's that's

the same kind of thing with darks you

know you could if you look if you look

at gear to M or whatever through the

right glasses um you could think of you

could think of the diff to the previous

revision as being the first class

objects in that system but really um it

doesn't make it easy to work with it in

that way um darks does its very best to

um to make it easy as possible to treat

Pat patches as the as the real unit of

work in a in a dark

repository um so what does it actually

mean in practice um so one of the really

key benefits that you get from using

darks is that cherry picking changes so

is very easy very it's encouraged by the

user interface um it's very cheap um and

once you've done it um once you've

Cherry Picked a change and you decide

you want the you know the changes that

you skipped over when you did the cherry

picking you pull those back into your

repository and you've got exactly the

same thing as you would have had if you

pull them in the normal order okay so

darks kind of gives you and I'll show

you um I'll show you that a bit more uh

in My

Demo um and whereas if you did that in

git you'd end up having to um you'd end

up with two different two different

repositories you'd have to merge the two

to get get back to the same

state um the other thing about darks is

that merges a deterministic so anytime

you do a merge in darks um it will give

you exactly the same result wherever you

are in the world whatever version of

darks you're using um if it would the

and the behavior of the merge will just

depend on um what what darks chose to

record at the time you actually saved

your

patches um from the point of view of

user of darks we like to think that we

have a simple intuitive user model if

you just sort of start using darks um

without knowing how to do so you know we

hope that you'll quick quickly get to

grips with what what's going on behind

the scenes enough to understand how to

use it but not not really need to

understand the the guts too much um and

you I think that's that's a criticism

that a lot of people make of git that

it's it's very hard to use it well

without having expert level knowledge of

um of a large portion of the um of a

large portion of how git works and how

you're expected to interact with it um

so by contrast again darks tries to have

a simple command set um another thing

another philosophical point about darks

is that we try to make commands

interactive by default so you know when

you've got got some options about how to

about how the what you could do with a

command and rather than having to pass

some Flags to figure out exactly you

know to get that behavior um darks will

try to ask you questions I mean not it

it that's not entirely the case but it

will it will ask you questions about um

what would you um how how much of this

would you commit would you like to make

for example that kind of

thing so what doesn't darks have um well

a whole load really um so the features

that people tend to find missing most

more and more are um multi multiple head

repositories so in darks you you have to

have one directory per um per checkout

basically per Branch so if you want to

branch and have two different things in

flight and switch between them you need

to just use two different directories in

your file system um hopefully we'll fix

that at some point but it's not not

trivial um and some people argue that we

shouldn't do it but I think we've most

of us most of dark developers concluded

that we should um darks makes a mess of

conflict handling if you have

complicated conflict so simple conflicts

aren't particularly problematic um but

when you start having conflicts with

conflicts and that kind of thing the

both the user interface and the

internals of darks tend to get a little

bit upset um I mean so you know in

practice people don't run into this very

often I mean darks works fine with small

to mediumsized repositories it doesn't

really work brilliantly with really huge

repositories um and another part of that

is another point on here that it doesn't

it's not all that

fast um it doesn't have unique um

revision identifiers for a particular

particular state of the repository which

really annoys some people cuz you know

things like G to even subversion you

just say here this number represents an

exact state of the repository you give

that to somebody else and if they've got

enough State they'll be able to

reproduce that exactly what you

had

um and really these days what darks is

missing is is not GitHub um and of

course it doesn't have the whole set of

tooling or in fact a large user

Community around it any well it never

did have a large user Community but it's

shrunk a

bit um and yeah it's not not all that

fast but

still what about code

complexity complexity for

what

um it okay without if there are no

conflicts involved then I mean that I

mean s emerge okay so emerge emerg in

DOS is more is ASM totically more

complex than emerg in git if you've got

a very large um if you've got a very

large history leading up to the merge so

if you if you've branched and you've

done you've made 100 changes on each

side and you've got say one one file

repository then in dark's emerge will

scale with the number of changes that

you've made um on each you know like the

product of the number of changes on each

side um whereas in get it would scale

with the number of um with these well

with the size of the tree roughly so

that that's kind of I mean it's you know

darks might be faster probably wouldn't

be but um it could in principle be with

you know just a single change well maybe

not is the word

do you mean with ter in with respect to

conflicts or with respect to just

merging in

general right so yes I mean so it is

quadratic yes it's the product if you've

got if you've got two branches 100

changes on each side of the branch that

are not that are unique to that side to

that Branch to the each separate Branch

then it will be 100 times 100 will be

the the amount of work dark has darks

has to do to merge those those

changes um I mean I

think I don't think that's such a big

big problem in practice

um

sorry yeah I mean so if you get

conflicts then that is a real problem um

but if you don't get if it's just if

it's a clean merge um yeah I mean I

think I mean that is a significant point

that it does it does do these merges one

step at a time um but I don't I

personally I don't think you run into it

that that often with sort of at least

mediumsized

repositories um

okay so I'll dive into a demo now um so

there are some people who haven't seen

darks so I I guess I'll go into it

properly

um okay

so um I'm going to start by making a

dark's reposit a directory to hold my

repository um can everyone read this

okay I think I checked from the back

earlier so I think it should be all

right okay so I'm going to keep my

repository in this directory and the

first thing I do is do a dark in it um

do well just get get the basic metadata

in place get this make this be an in

make this be an empty

repository um and then I'm going to copy

in a um a simple source file that I

prepared earlier for the purpose sorry

um so just to show you what's in that

file for now um it's just sort of a very

basic high school program that I shall

make make a few changes

to okay and so the next thing I need to

do is tell darks that this file exists

in my repository and it's something that

it should

track so darks

add and so in darks um there is a um the

command the equivalent of what might be

called commit in many other Version

Control Systems is called record um so

which means record a patch um so I'm

going to run that

command

and uh it scrolled

confusingly because I've zoomed in too

much now I can't find my mouse pointer

sorry

okay

um is it going to be okay if I make the

font a bit smaller so I can actually see

the full

width right is that still readable for

everybody

okay um all right so dark is just going

to um now is this is what I was saying

about it being interactive before it's

just going to ask me about what I've

done and what I've done is I've I've

added the file and I've put some

contents in the file so um I'm just

going to record this

initial um this initial patch so this is

just the in initial

version okay so then dark asks me some

stuff about um just confirms for sure

that I want to record exactly what I

said I wanted to say record and asks me

what the name of the commit name of the

patch is going to be and if I wanted to

it would bring far up an editor and let

me edit um put a longer comment than a

single line yep question the first CH

was adding the file yeah second was

adding the content that's right yes

um so you only need to do the ad once

file that's right yes I mean it's

exactly the same as tracking a file in

any other system you just it's so that's

otherwise it I mean there is also I

could have also done this by saying

darks record- L which says looked for

ads and it would have then gone off and

looked for every file in the repository

and let me add that so um it's just it's

a trade-off between whether you want to

have untracked files to worry about or

not okay so I'm not going to add a long

comment okay so now I'm going to edit

that file

um okay so I'm going to make a couple of

changes to this file um so firstly I'm

going

to I'm going to just add one more um one

more thing that the this program is

going to

do and secondly I'm going to change one

of these messages that it's already um

that it's already printing

out

okay and then I'm going to come back and

record that changes so um darks allow

accepts prefixes of any command that it

normally um that it that that are unique

so I can use wreck as a synonym for

record which I at least personally find

quite useful

blast

um okay sorry my Demo's just g a bit

wrong

um so what what I was okay so what I was

hoping at that point was that dark

actually I can no this is fine I can

still do this um so what I was intending

for at this point when I did um was that

darks would ask would give me those two

changes as separate um as separate

changes to the repository but what it's

done is it's decided that it's decided

um it's decided that the diff that this

all lives in one part of the diff so

it's showing me showing me two changes I

made at once and since I actually want

to show you how it will treat those to a

separate changes that's a bit

inconvenient um there going to sorry

there is still going to be a second

change yes but it's not going to make

semantic sense when I start making other

changes to the patch so what I'm going

to do actually is bring up something I

wasn't intending to show you um which is

the interactive um interactive editor

for um for CH for changes that you make

that for um for patches that you're

recording so what I actually wanted the

darks to do was say Okay I want I want

the addition of the exclamation mark to

be to be one change and I want this say

goodbye to be a different change so what

I'm going to do here is just edit this

kind of intermediate state that darks

has presented me with to say okay well

the first change I want you to show me

is that addition of the exclamation mark

and then the second change you can show

me will be the addition of goodbye

um okay so um oh actually yeah sorry and

what I actually wanted to do was so I've

gone I've used K to go back um because

what I actually wanted to do was record

the addition of the text first and then

the addition of the message for reasons

I'll explain in a minute change this

message so I shall say no to this one

and I'll I'll

blast

[Music]

all right fine let's

um okay I'm going to I'm going to start

again with this so this actually works

out properly so I'm going to so now I'm

jumping around in what I was actually

intending to do um us usually this kind

of thing doesn't I mean this you know

this this kind of problem where darks

wants to show you changes that you

didn't um that are stuck together in

ways you didn't quite expect um is less

likely when you're working with bigger

repositories because the changes that

you make are more likely to be widely

spread across the you know AC um either

inside a single file or between or

between different files um what's

happened here is I've tried to make a

very small demo um and as a result

everything's um the diffs that it's

asked me about are not not quite the

ones I wanted um put in

before um so what what I'm actually

going to do is just go back and put some

lines in so that it doesn't it

definitely gives me the diff I want just

to cheat a bit really um just to make

this demo work quick at least reasonably

quickly okay so I'm I'm using a called

Dark revert now which um that's what rev

is short for um which just offers me the

changes that I've made locally in my

repository and says do you want to throw

these changes away um and again it's

offering them to me one at a time so I

can just um but in this case I want to

get rid of all of

them okay so what I'm going to do is

um sorry supposed to be high

school

sorry can't use y

either

okay okay so now I'm going to do those

make those same changes again and

hopefully this time it won't it will

offer me those changes

independently if I can work by which I

apparently can't

um excuse

me oh yeah thanks I wasn't actually

going to run the program so it doesn't

really matter matter

but I like I like people to think that I

write valid

hasal okay so that's one of the changes

I could um that I could record which is

the addition of the exclamation mark and

the addition of the goodbye message is

the other change that I can record um

and what I'm going to do and I mean

clearly I could record any of these I

could record any subset of these three

things that I chose to yes sorry my

question is chain yeah say that now the

line between the changes has some has

some content in the previous case it was

an empty

but okay so the only reason it's

different is because the um is because

it's a heuristic Andi it's a heuristic

in diff so at the point so I mean I

guess this is jumping ahead a little bit

in some sense but if you um when when

you do a three-way merge in any Version

Control System what will happen is that

the Version Control System will will run

diff between the between the between the

base of your merge and the two the two

options and then it will try to merge

those changes and at the point where it

runs the diff um there are usually a

there are usually multiple choices for

what kind of diff you can

get right and so the what what's

happened here is that because there are

two blank lines in the file um the

choice about whether to line up the

blank lines with each in in the old file

in the new F in the old file there was

one blank line in between the say hello

and the um and Main and in the new one

there was a blank line between say hello

and goodby and say goodbye and there's

another blank line between say goodbye

and

Main so how diff has chosen to line up

the blank line between those between the

old version and the new version of the

file is what has affected the what's

been presented to

me and so what I did was I changed one

of those blank lines to be something a

bit more than just a blank line thus

forcing it which meant that it couldn't

possibly line those two

up for

me

really the Reas so the difference is

that that line with content when I added

the when I added the first I didn't copy

that content I put a blank line in so

the blank line is different from the

content that was that was there

before so if you so if I um so if you

look at

um yeah yeah it's it's really just it's

really just blank lines getting it diff

getting a little bit confused about it's

always istic that that diff

applies yes exactly so it's just all the

dark is doing at this point is get

making a diff and presenting me with the

individual pieces of that

diff doesn't make

the uh the number of chain sets too

large if you're just editing the P not

subsequent lines but just having one

line one line one line

this part of the line but this is n

Chang for me mhm so it will darks will

offer you all nine changes individually

um if yeah um if you've if you made

changes that are separated in the file

um and you do have so this this

interactive prompt actually has a bunch

of um a bunch of commands that bunch of

keys that you can use at this point to

to choose you don't have to say yes or

no to every single um to every single

change so the the standard thing you use

in that case is you if you know you want

everything that you've done into that

file then you just press F to say record

all changes to that file um or record

all further changes to this file so you

can you know for example if you've made

some change that you didn't want to

record you'd say no at the beginning um

and then you can say or a for example to

record everything that it's going to

offer

um okay so yeah so right now I'm going

to record I'm going to record this the

addition of say goodbye and the call to

say goodbye together so that those those

live live together with an atomic change

set an atomic

patch once you recorded those two

together kind of like stuck together

forever yes um yeah pretty much

y you two up three yeah what happens to

the original file that the the file in

the the file in your direct when you're

doing a record the file in your

directory doesn't get touched at all um

all you're doing is recording is

changing the sort of you know the

current version controlled state so

there's always an implicit diff between

what you've done in your direct your

working directory and what's what the

what the state of the very last Revision

in the repository was and so that diff

has now got smaller but the actual file

hasn't

changed um so on the other hand if I'd

use revert which is about changing the

changing the state of your working copy

then I could have reverted some of these

changes and not others and then the file

would have been put back into some you

know some sort of State a little bit

closer to the work to the to the

recorded copy

but okay so I've

I've recorded a

change that's called i' say goodbye

which has that change in it and now I'm

going to record Another patch

that that incorporates the last change

that I had and nothing

else okay so now what I've recorded is

apart from the initial setup of the

repository I've recorded the change to

um I've I've recorded two different two

different changes firstly I've added say

goodbye and secondly I've changed the um

I've changed the text of

hello okay now I just remembered that I

forgot to clone this repository at the

time I intended to um so I'm going to

well I'm going to do it now anyway um so

I'm going to clone I'm going to clone

the repository that I made um into

another one um and that's dark's get is

the um standard command for doing that

and you can use that with remote remote

repositories as well um and because I

forgot to do this at the time I intended

to which was before I recorded that

change I'm going to delete a couple of

changes from this repository using um

the obliterate

command Okay so and now I'll get back to

what I actually intended to do at this

point which is to show the pull command

which is about moving patches between

repositories and now this is the point

where I'm going to show you how cherry

picking Works in darks in a sort of

simple intuitive way so if I try to pull

from repository one it's going to offer

me the changes that I made to um that I

made to that repository um in the order

that they exist in that repository so

this is a set of changes that are in the

other repository not in my present one

um and it's going to show me them in the

order that that they would live in that

one you got comment there that's the one

comment yeah you see the code um

yes um so X will give me a summary of it

and V will show me the code um though

there's a little bit of metadata that

probably would be more user friendly to

have to have Allied but

[Applause]

yeah okay so at this point I'm going to

I don't want to I don't want to say

goodbye yet I just want to make that I

just want that hello change but that was

the second change I made so I'm going to

say no to this and it's still going to

offer me to offer me offer me the Hello

message pull

so I'm going to pull

that and um there we are and if I have a

look at the contents of demo. HS now

it's got that change to it's got that

change to hello but it hasn't got the

change to goodbye even though that was

never one of the recorded states that I

made in the previous

repository

is I disconect this CH no okay no it's

not um it's no it's not available

locally so if if you wanted that then

what you would need to do is clone the

Clone the entire repository and then

into a different directory and then

start pulling from that yes

um and in fact that's the way I

typically use dos if I'm when I'm I work

on the train a lot I I will just do a

pull from from the Upstream repository

to somewhere and then work work from

that

locally okay so yeah so I've got this um

I've got this change that was um that

was one of the two changes I made but

not in the order that I made it now I'm

going to go back to the other repository

and I'm going to use um I'm going to use

a command called darks

replace so darks replace is a search and

replace operation on your Repository it

takes um so what if I show you demo. HS

I've decided I want to rename the print

message function to something different

so I'm going to I'm going to do darks

replace print message output

message repo1 um not repo one sorry

demo.

HS okay now so firstly i' to emphasize

that this is a pretty dumb search in

replace right it doesn't take any

account of language semantics or

anything like that so if I had if I had

a variable called print message

somewhere else in scope then it would

happily rename that that as well

um okay so now I've done this

replace um it's changed my file for me

but it hasn't actually recorded a patch

to say this is um this is a change I

made so I'll just I'll just do that um

and the change is actually expressed as

this replacement

operation and yes I want to record

that okay so just looking at demo. again

you know that there's been there have

been a couple of occurrences of output

message of what word print message that

are now output message that have been

changed by this replace operation now if

I go back to repository

2 that doesn't actually have all those

call all those call sites for print

message because I didn't pull the change

where I said called say goodbye as well

um but if I pull from repository one I

can still ignore the say goodbye change

and I can pull the print message

change and what's it done to my file um

sorry okay well it's it hasn't pulled to

say goodbye so there's no there's no

change there um but it has um but it has

renamed print message to Output message

correctly and finally if I pull again

from repository

one and I bring back the say goodbye

change I could also shown you that patch

I did it it's pulled back say goodbye

this say goodbye change which was

originally recorded as an additional

print message um but now in the context

that it's just been pulled it's an ADD

of output message because that's what

that that's what makes your program make

sense um now that's only true because

the replace was a safe thing to do on my

repository um but nonetheless it's still

it's um it's done the right

thing um and so the other point about

this is that now this repository is

pretty much identical to that first one

there's no other changes I can pull from

the other one if if I sort of ask darks

you know are there any differences

between these two repositories it won't

there won't really be any um

sure okay

so darks Chang so darks changes is just

a list of um list of what patches you

have in your repository in reverse order

um and as you can see in this repository

it's this way around and in the other

repository it's um you've got them in

the order that I originally recorded

them mhm something which has the print

message inside

yeah and I want the print message to be

there and then put that change

into you want to keep the print message

you mean yes

um so is this

side okay so if I was to take if I was

to um now start editing after this

rename operation and put a new print

message in there right then that will be

that will be safe because it comes after

the replace but if you've if you've got

if you work in a repository that hasn't

seen the replace already but you have

the yeah but I mean so either repository

it doesn't make it doesn't really make

any difference now but if I I mean I can

I can safely change demo. HS now and put

in um no no no what I mean is if you the

change set which

had well it was originally recorded with

the print message change yes

CH which

hading message the

result and and you put it on top of your

already

replaced yeah still it's saying that

it's

message um well that I mean I I think

that's I mean that that was what was

expected to happen because the if you

look at it from the other repositories

point of view the replace was operating

on both print

messages

so um so so in the of the first Chang

the first one uh uh replace the names

and a change which is change uh which is

explicit have message

inside um so in so that I mean that

that's the that's the point of what

darks has done here is that it's decided

to it's it's changed the behavior of

that it's changed the contents of that

patch because of the order in which it's

put them um

so

um in which repository in repo 2

okay

so so there so the patch itself has been

changed by this op by the by the fact

that we've reordered it to say this

patch says this patch is an addition of

output

message it doesn't have the exactly the

same text in it and that's exactly the

point of having first class patches that

your um that dark will change the patch

so the point is that darks has tried to

preserve the meaning of the patch

right so the the meaning of the

repository that we

had

um so I mean that's that's the point of

using replace right you're you're you're

kind of asking darks to do that you're

saying that so looking at it from

another point of view right you've so

let's let's say that I've been

developing a program um with print

message in it and then I decide I'm

going to rename print message to Output

message okay and in parallel to that

somebody else decides that they're going

to add a call to print

message okay I'm

just I just don't know I

like y fair enough well

okay yeah so I mean I think I mean

otherwise if if they if pulling the say

goodbye had resulted in print message at

the end of repo 2 that would have been

tot that would have been incorrect right

I mean it wouldn't have actually been a

functioning program so if you want this

property about cherry picking and so

forth where you can get patches out of

order and then pull the other ones back

it has to do

that guess that's another way of

justifying what I did if you don't like

it but um

anyway kind of I put it in yes I think I

think of outut message and then kind of

like and out the

re take

that so if you um if you add if I now

added an output me a call to Output

message in my repository afterwards and

then I and then I unpulled the replace

um removed the replace patch it would

change that to print message and that

would be correct but the name capture

point that I I thought maybe you were

asking was that if I had say a local

variable called print message or output

message depending on where I in which

state I added it then the replace patch

is going to do the wrong thing with that

so you know if somebody else in another

branch has decided to write a function

that internally uses a print message

variable of its own yes I

supp it won't it w't if you do that it

won't let you do it so there there so

part part of the darks user interface is

that it will detect detect things that

don't make sense like from

a yes

and repl is global I

it's file by

file um there is no patch type for

moving code between different between

places in files um it's something that

we would like to add um but yeah we

haven't done it

yet okay

um

okay so I was um I've already shown you

rever actually no I'll show you a bit

more of that um so if I just edit demo.

HS a little bit more

um just add some garbage in two places

and I confused

by

okay so I've just added a couple of

lines um and now I want to get rid of

those lines and again as I showed you

before darks offered those independently

so I can say revert just the Wibble bit

and then I'll be left with wobble in the

file and then I can revert that as well

and that's gone um darks also has an

inverse of revert so darks tries to make

most operations undoable there are cases

where you that's not really feasible but

um for example darks has this

unreversed um but not the one before

that so I can't get Wibble back

anymore

um okay I'm going to change some the

file this time and keep the changes

um so I'm going to change this text

to

and I'm going to record Another change

with that that in it oops I forgot to

get rid of that never mind I'll do that

in a

minute

uh sorry my laptop's frozen

up

um I think it's frozen solid this what

you get for running

Windows um I'm going to have to reboot

it so

[Music]

I think it I think actually this I think

it may have Hardware problems of some

kind it's

occasionally well I mean all I can say

is that my dark my laptop does lock up a

lot and I do run darks in it a lot

but I I think it's a hardware problem

I'm not entirely certain I'm sorry about

this um so what I was about to do then

was just record that patch and then I

was going to show you how you can use a

command called aend record what the



okay I'll give it a little bit of time

to

[Applause]

um yeah so what what I was going to show

you at that point was um editing a um

editing a patch that you've already

recorded to add add some extra changes

to it um and I'll I'll just do that next

just to um is there kind of longm to

extend yes um but that that's

particularly difficult so the problem

with the with extending it to know about

syntax trees is that you have

to um you have to fix your paa um you

have to decide that you know this this

one paa that that exists right now is

the one that's actually going to we're

going to um we're going to use to pause

the codee um so you know if if the

language changes a bit it become you you

end up having to version

things so that's probably a reasonable

way down the

line um

actually uh yes sorry but you you have

to keep you you still have to keep the

old one around so that you can read old

patches

so yes you can record new patches with a

new paer um but then you have to figure

out how you merge between the patches

that were recorded with the different

paers um and you have

to

[Music]

you kind of imagine you're creating your

P by recording MH and then you've got at

some point

patches yeah you

need no no yes you're ask you need to

have the paer at recording stage but you

do need to the kind of meaning of that

tra so the pretty printer you do need to

have everywhere you need to be able to

invert that you need to be able to

invert what you recorded to to actually

you know show the user what the real

Source would be if I really wanted

to

and literally just Tex so us it four

times it might L change treat that as

yeah so absolutely so so then and then

you won't get that nice that nice

behavior I showed you where it break

start yeah so it will f it will refuse

to it will refuse to let your cherry

pick around that then

um okay let me record this change as I

was trying to do not that one I

can't exactly

okay and I'm going to revert that other

change that I forgot to revert

before

um okay and now I'm going to make

another change to this

file um

just

okay I won't bother calling it that'll

do okay so now this time instead of

recording a separate change for this um

for that edit I've just made I want to

actually incorporate it into this other

patch because I think that the two

belong together for some reason I mean

in this case they don't really

but and so the command I can use for

that is dark amend record and that says

that will go that will go back and say

okay here's a here's a here's the patch

that you just recorded would you like to

change that um sorry I was going to do

that with a flag saying edit allow me to

edit the message as

well so should iend this patch um yes

and then here's here's the change that

I've just made to my repository and

shall I add this change to the patch

that you've already record that I've

already recorded yes um and also give me

a chance to edit the message so I

say

add okay um so that's you know that's

use if you're kind of working with draft

patches as you go um and then you start

you want to sort of keep adding changes

to them um and then eventually you're

done with it and then you say okay I'm

going to send this off to other people

and at that point you should stop

amending

iten

you so if you if you make a change P it

to the other repository then amend the

change and pull it again it will look

like a different change and it will be a

conflict yes so you then have to go man

un pulling the other

one okay um so okay let me just go back

to my slides for a

second

that work

yes okay so I've shown you quite I've

shown you a sort of bunch of the a bit

of the basic command set of darks and

just sort of what the what the sort of

model is um a new command that we're

adding to Dos in the in the next release

that will come out in probably the next

few months is a rebase command um and

rebas is a concept that exists um in in

systems like git and so forth and it

hasn't existed in darks before um and in

part that's because some many of the

things that you'd want to use rebase for

in git aren't really necessary in darks

um because you don't you don't you don't

have all these merge commits with darks

um that are about that you know you

where you want to um because whenever

you do a merge you always get the same

results so dark doesn't have to present

you with a merge commit um and you don't

need to use um rebase to do cherry

picking which is another thing that um

it's used when git but nonetheless there

are things where there are cases where

you do want to use you do want to do a

rebase you want to change

a whole sequence of patches in your

history so that they're maybe more up to

date or so forth so um we're adding a

rebase

command

um and so the basic so the way that the

rebase command works is it kind of puts

your repository into a temporary state

where you're doing some you're doing

some work on some patches and some other

patches have been sort of suspended um

and then you can bring those patches

back into your repository with an

unsuspend command so I'll just show you

that

now uh except for

that what

happened okay so I'm just going to um

I'm just going to throw away my that

change I just recorded and do the same

thing again um but with with a slight

twist to

it which I can

use

never mind about the typo um and I'm

going to make a second change on top of

that um which is that I want

to

I also want to write this to standard I

want this to go to standard error as

well so here's my second change which is

use standard error okay so now I want to

do that amend that I did before I want

to add that extra I'm going to put that

call to say we back

in and like to change that patch that I

wrote before the one where I where I

changed the message I want to CH I want

to insert this say we into that that

patch again so I don't want to edit the

standard error patch so I say no to that

um oh but then darks isn't going to let

me do um do that amend record on the um

on the update message patch which is

what I actually want to change um

because I've made a patch on top of that

that depends on that patch there's no

way that those two patches can be

logically untangled from each other

because darks is a line by line has made

a line by line diff and this the diff

for the standard error lives directly on

top of the diff where I change say to

wants to say um so I'm out of luck if I

want to amend it and that's where rebase

comes in so rebase will say okay well

this standard error patch is in the way

now let's let's push it out of the way

for a bit

um okay so that's that's disappeared

from our repository and it's now

suspended so if I just look at the

changes in the repository you can't see

it anymore um but darks will keep

reminding of the fact that it's still

around if you um and that you can get it

back okay so now I

can now I can amend this patch

um okay great um so done that now I want

my suspended patch back now how's dark

going to deal with that because well I

mean it's we haven't magically got

around the fact that the um that the

change the second change I made that to

insert standard error really does depend

on that first change I made sorry will

you wait no

um okay so well okay it's going to let

me unsuspend it it's going to offer it

to me we

are okay now that's I think there's a

bug in the development version I just

used because it should have told me that

it actually had a conflict um

huh oh right sorry now I got this demo a

bit wrong that's fine this is so this is

that that that bed was actually supposed

to happen and it was it was just not not

quite what I ended to do with the demo

um so what happened here was that I

didn't um I didn't when I when I changed

that patch I didn't change anything

about the line that was actually a

problem right so the con there should

have been if i' if I tried to do

anything to the output message text then

darks really would not have been able to

figure out how to bring that patch back

un suspend that patch into my repository

but because all I want all I did was

added say we to that change that was

fine that um it was able to do that now

because of some technical technicalities

to way the internals of darks works it

still has brought this patch back with a

different identity so it will actually

clash with other patches in other

repositories even though it's it looks

like exactly the same patch but now let

me just show you what would have

happened if i' done what I intended to

do there um okay so I'll suspend that

one again and this time I'm going to

edit HS to also say something different

here so

um can't make up my mind which editor I

want to use okay so I'd like to do that

instead okay and now I can I can change

this update message so that it's now now

a patch that does

this okay and now if I um if I unsuspend

this patch okay then it tells me that

that things have gone a bit wrong that

it can't quite it can't quite unsuspend

this patch and have it have it be a same

patch

locally and it's also um inserted some

conflict markers into my repository

which is dark's unique style of doing

conflicts um to tell me to to to give me

the local changes that have gone wrong s

go it just well it's I mean yeah it

marks up your repository like like most

systems would it um it lets you do the

operation but says there's a conflict

and here's and this is what the conflict

is in terms of

I the uh in this case is the fact which

complet be

your changes support mhm is still in

your

yes so the the original one that was the

cause of the conflict is still there I'm

fine and this one is in a slightly

conflicted state that I'm now going to

I'm now going to fix the conflict

and yes um okay so sorry um I haven't

shown you conflicts in the normal case

of merging and in that case it really is

another patch on top of it when you're

using rebase the normal thing to do is

to fix your conflict and then amend that

into the patch you just unsuspended so

um I won't bother doing it here because

it um I've I've already spent quite a

while in this demo that I didn't intend

to but um what's so what this conflict

is telling us is that well the first

line is the base of the conflict before

the equals so um that was the original

state and then there are two different

changes that are conflicting with each

other one of which is to insert the

standard error and the other of which is

to change wants to sat to would like to

say so our job is to you know see that

and do do the do the change for

ourselves and then then edit the patch

that we just unsuspended to to bring all

that um to bring that into

line okay

um let me go back to my talk I did that

bit of the demo um this is just a quick

slide just to show you that the main

sort of set of

command oh sorry wrong way around um

thank you that would be a

good yes in fact so another re another

place you wouldn't another way we thing

we could do that would mean you wouldn't

get a conflict there is if we did

patches to us to the characters of a

line rather than to rather than a line

by line thing and that's probably more

more in reach as

well okay so just just to give you a

very brief overview of the sets of

commands that you you can do with darks

um you know how they how they all fit

together so one interesting thing is the

sort of specific kinds of patch types up

here um so I already showed you replace

and add um and move um moving a file

around is also a kind of operation that

nicely with and merges nicely with other

patches um that you know also add files

and so forth um some standard remote

operations get in its mirror put pull

and push um obliterate which is to

remove a patch which used to be called

unpo and still has the

Alias um there is a staging area called

pending which we tried we we do our

absolute best to hide from you unlike

git um so pending is used for things

like in fact things like replace um so

something that can't be something that

really can't be represented in the

repository um then we put it in the

staging area so you know if we if you've

made that semantic statement that you're

making a change to your repository that

you you can't just infer that from the

files then we'll then we put that into

pending um otherwise it will be just in

otherwise you just record what's in your

working

directory it doesn't make sense

because the way how

you changes is actually uh so what when

you assembling your your story is

exactly what when you are just saying

this is record changes

yeah yeah I think I think that I think

that so the mixture of that and also the

fact that amend record is designed to be

fairly user friendly are two things that

make it I think unnecessary to have that

index have that equivalent

um okay and yeah there's some functions

for quering a repository you know just

but there's you know to for basic

operation with a darks reposit you don't

need to know um all that many commands I

hope I'm getting across with

that okay so um let's just go into um a

bit more technical detail about um

what's inside a dark's repository um so

dark's patches are semantic descriptions

of what should um what should happen to

the previous tree to give you the new

tree um so example of um an example of a

darks patch is remove the text X that

starts at line three in in a particular

file and put text Y in there

instead um another kind of dark patch

would be add file a or rename file C or

replace token x with token Y in a

particular

file um an important property of darks

Patches from the point of view of the

internals of darks is that the patches

are invertible um so any anything that

you can record um in darks darks has to

know how to undo it as well so that it

can kind of get back to the old tree um

that was before that um so for example

so it is actually important that you say

remove X from the patch at line three

you can't just say remove one line um

the internals of darks were actually

record the fact that the old version was

X it won't be able to use

what World card um that's correct yes

yeah um I mean that's not to I mean it

it can't but that's not totally I mean

if you if you had a linear regular

expression it would be possible it would

be technically possible we just have we

haven't done that and it would probably

be quite confusing but yeah as long as

long as you're sort of replace was was

invertible in some way you could you

could Implement

that um so yeah so that I mean I'm not

going to go into the details of why

that's important but it it is it is one

of the features of you know getting this

reversible cherry picking operation kind

of requires that you're you're able to

manipulate patches um in that kind of

way and inverting them is one of those

properties um I guess another Point

that's worth about how darks patches

work in general is in most Version

Control Systems you're kind of committed

to this this series of changes that you

made in a particular order whereas darks

lets you sort of pull out random random

changes from the middle if there's no

textual conflict um and that means that

of course you can write you can pull out

changes that really doesn't make sense

to pull out um because you know for

example if in one patch you add a

function and then in another patch you a

call site to that function and then you

try to cherry-pick the call site of that

function on its own darks will probably

let you do that if they weren't weren't

right next to each other um but you're

not going to have a meaningful

repository um but that's some power that

it gives you that you can you have you

have to decide how to use

it um yeah so I've already kind of

alluded to some of this stuff before so

and merges in dark are deterministic so

every single time every time you do

emerge anywhere with two darks patches

that were recorded at the same um that

the original darks patches then you'll

get exactly the same result and that

means that darks doesn't create merge

commits when you actually when you do a

merge okay so if you get a conflict then

you have to record a new patch to

resolve the conflict and then you've

kind of got an equivalent to merge

commit um but there is no explicit sort

of marker in darks in general for a

merge happened

here um

and merging is associative so say you've

got three repositories and you decide to

merge two of them together and then you

merge it with a third one um you will

always get the same result as if you

merged the second two as your first

operation and then merged it with the

third with the initial with the first

repository um so I mean that that's

that's I guess it's kind of part of the

intuitive user model that we're trying

to get with darks that you don't really

have to think about what audit what what

things happen you you just when with the

darks user interface it tries it tries

to make that implicit that that you can

expect that to happen without having to

think about it and it's it's kind of

important that that it actually is true

you don't get nasty surprises that

way

um okay so going a bit more into the

internals of What's um of of how this

all works

um

so on the left I've got the kind of sort

of diagram that represents what happens

when you have a merge operation so we've

got two different repositories with

patch a and Patch B in them that's the

difference between them and so the base

of the merg is um the bottom leftand

corner and in two different in the two

different repositories we're going to

end up with two different two different

states of the reposit

and the the point of a merge operation

in any version control system is to

figure out what should that question

mark be um and then do do the

appropriate thing with

that um and in darks what we would do

when we do that merge is that um

supposing we were pulling B into a

repository that already had a um we

would compute what that we would compute

this alternative version of b b Prime um

that is so kind of the same effect as B

but in a different context it's now

living after a and if depending on what

depending on what A and B were we might

actually have to change B into something

slightly different for that to still

make

sense

um so the dark has this internally has

this concept called commuting which is

changing the order of two patches um and

that's what I'm trying to get across

with this diagram is that that really is

just the inverse of the merge operation

so um with a merge you have two patches

that start at the same place and you

want to figure out what how you how you

combine them and but an alternative way

of looking at what the sort of work

involved here is that you have two

patches that are already in the same

repository in sequence and you want to

figure out how to unpick that you want

to get back to two patches that are

totally separate from each other um so

if you already know A and B Prime then

what's

B okay and that's that's the fundamental

part of cherry picking because once you

can do that um if you can swap the order

of patches then if we don't if we've got

a repository with A and B Prime and we

don't want a we just want B Prime then

what we have to do is commute A and B

Prime to turn them into B and a prime

and then we can throw away a prime and

we've got a repository just has to

change B in it um and when we do the

merge again um because of all the stuff

that darks does behind the scenes it's

going to give you exactly the same

result B primed again so that's that's

why what I showed you um that's that's

kind of a flavor of what's behind what I

showed you it's not um there could be

many be

a there could be many so um in in the

merge diagram there have or in any of

these diagrams there has to be unique

darks that's one of the things darks

ensures so if you given a prime you

multiple ways of

facturing yes but they you have to um as

darks will to if you adding a new patch

type to darks that would define what

this commu would be you'd have to do it

in such a way way that um it would go

back to B Prim when you merged it again

so otherwise you'd break darks um

so

I

[Music]

a

will B Prime uh B primee yeah so it will

store them in a particular in the

particular order that's useful for that

working that repository per repository

yes

exactly okay so yeah this actually goes

into so I mean conceptually you can

think of a dark repository as being a

set of patches in most cases right so

the the set of patches you got in your

repository no matter what order you

brought them in in the end state of your

repository will be the same um but they

are they are actually stored in a

particular order that reflects how you

got them um and you know when you run

things like darks changes as as we

showed you that um that does show

up um there it's rare I mean I think it

there is a user demand for that kind of

thing because you know you want use

quite often want to see what's what the

changes in your repository are that it

isn't in a remote repository and it' be

useful to reorder the patches in your

repository so that just your local

patches are at the end of the repository

um so and we don't have a great command

set for doing that we do have one

command that lets you do that does some

of that for you um but it's

not uh that would be Overkill because it

would change the identity of your

patches so you you really wouldn't want

to use rebase for that and there's a

command called darks optimize reorder

which will do that up to the last tag in

the repository but it's not it's not

sort of General

um yeah so there's this um there's this

distinction in in darks in terms of well

I guess in terms of both the mental

model and in terms of the internals that

patches have an identity which is the

thing that you know they they retain

that as you pull them around between

repositories but as we saw the

representation of a patch can change as

you pull it around um and that you know

due to either merging or cherry pitting

depending on which way around you um how

you're pulling it

around

um so I mean there is this kind of

there's there's this kind of theory kind

of hiding at the uh hiding inside darks

and hiding very well because no none of

the people who really work work on darks

have managed to make a really formal

theory behind um behind what's happening

with these patches and it's that's a

real shame because it ought to be um it

ought to be possible to do um just

nobody's Managed IT um but we kind of I

mean I was sort of alluding to various

things that you have to get right

otherwise you'll otherwise you'll screw

up the behavior of darks and we kind of

intuitively know that the these things

have to behave this way and you know

there so there are some laws that we

believe are true about um all the dark

patch types that we have and that would

be true about any new ones that we added

so an important one for example is that

if you commute two patches if you if you

had a and you swap them around if you

swap them back again you're going to get

back to the same

result um so just the equivalent of

these two commutes um and also that if

you um if you kind of if you invert

patches and start commuting the inverses

then you get the same result as if you

were as if you left them uninverted to

begin with um I just put that up I don't

want to explain that that in

detail um another thing I'm used quite a

bit of time so I'm just going to go over

this very quickly is the um there's this

I said that merges have to be

associative um and the thing that

underlies that in terms of what your

patches have to do is that um if you

start commuting patches around so say

you have your patches in the order a b c

to begin with and then you start

changing some of those patches around um

and you keep doing that you can you kind

of tra you're kind of following a path

around this Cube if um picture and um

there's no absolute guarantee from any

sort of external source that you'll

actually get back to exactly the same

results when you've got to the end of

that because the commutes that you've

done in each case are are independent of

each other um but that's another law

that we expect to be true that you will

get back to the same result um and if

you look at think of that Cube as a kind

of merge that's about guaranteeing that

you will that you know that top right

hand corner of that Cube will always be

the same no matter what merges you

[Applause]

did um okay so I'll finish up um fairly

briefly by talking a little bit about

the internals of darks and one one

particular way we've used um H or to

good effect in the

internals um so one of the things that's

sort of I hope of what I've already said

about darks is that when you when the

code of darks is working with patches

it's going to do a lot of time it's

going to be moving patches around

between different contexts a lot it's

going to be um deciding that okay this

patch um this

patch have these patches before to now I

need to cherry pick commute it or merge

it and so that it's got some other

patches um leading up to that

patch um and a lot of the time when you

do that the representation of patch

doesn't change because you know for for

example if two P if you've got two

patches to two different files the order

in which they're in makes no difference

their representation but you've got two

patches to the same file the order in

which they're in you'll have to change

the line numbers of in the offsets of

the second the patch that's further down

the file um so it's it's quite easy to

get this um to firstly get start using

patches in the wrong context in darks

code in in the dark source and if you do

that you might not notice quickly

because a lot lot of the things you're

testing with won't actually have won't

actually trigger that um trigger this

being a

problem um so here's an example of um of

how you might actually um of some some

code you might want to write inside

darks um so supposing that we've

supposing we want to commute two patches

we've got um the patch C and we've got

the sort of sequential composition of

two other patches A and B that's the

intention of this bracketing so I want I

want to get to sort of C primed and then

a prime as the or a prime B Prime is the

alternative okay so if if we take an

imaginary patch type which is um either

a um a null patch or nothing or sort of

two patches stuck together and then

obviously there' be some more

Constructors for the real um for real

patch kinds in that um you might write a

functional commute that's um going to

have a case that's for about commuting

commuting this um a as one group with c

as the other group okay so how you going

to do I mean typical hasal you're going

to do this kind of operation by

decomposing it into its sub pieces um

commute you know commute one of these

two things with the other with the next

one and then um and then commute um

commute the results to get it all into

the right order um so that's that's one

reasonably plausible way of writing it

that happens to be totally wrong

um because what you should do is I mean

if you just look at the order of this it

makes sense to commute B and C

first um and then commute the result

you'll get um you'll get ACB and then

you commute the result A and C yeah this

order but what what I'm doing here is

I'm commuting a andc first and a andc

aren't next to each other originally so

it really doesn't make sense to do that

um but there's nothing in this code

that's going to stop me from doing

that um because dark doesn't GHC doesn't

know anything about the context of these

patches so um one thing we introduced in

darks quite some time ago now is um a

way of actually telling GHC at least to

some extent these are the this is the

context of a patch um don't um don't let

me screw up so instead of defining just

patches as being um so the these um so

what I've done is I've introduced a

couple of type variables here and these

type variables are Phantom types right

they don't have any reflection in

reality in terms of the ACT you know I

could even I it doesn't make sense for

me to say patch in Char or something

like that that's that's not what they're

about um they're about saying they're

about a sort of abstract representation

of the context that that patch lives in

and and it means that if I write some

certain low-level operations carefully

um and don't screw up the context in the

lowlevel operations then the high level

operations that I build on top of those

um I won't be able to um the type

Checker will actually stop me from

getting it wrong so the the key point of

this really is that this sequential

composition operator now operation now

um says the context must match up so a

patch AB is a patch that notionally goes

from an initial starting point initial

context a to a final context B okay so

the sequential composition of two

patches now goes from an initial context

a via an intermediate context B um so

the um to a final context C so the the

sequential composition is a patch from a

to c and it's made up of two indivi

independent individual patches that um

start at a and finish at B and start at

B and finish at

c um and so to actually to actually work

with this kind of stuff you you find

yourself having to redefine a whole load

of basic type so what used to be just a

tle um I've now had to make a witness a

tle with these extra witness types in it

um that says okay this this is a sequen

this is a pair of patches that I'm going

to want to commute um for the to be able

to write the type of commute so commute

is now talking about the fact that we've

got a pair of patches that goes from a

to c in total and I want another pair of

patches that goes from a to c in total

but is in the opposite order

internally so I can I can translate that

that incorrect code I wrote in the

previous slide into incorrect code using

the um using these Phantom types and GHC

will complain um now the downside of

using these Witnesses is that the GHC

complaint takes a little bit of getting

used

to um

so what with you know so with some

practice you kind of get used to

understanding what it's trying to tell

you here which is that well um there was

some other variable B1 that would have

had to existed for this to make sense

but it it doesn't really work um and

um and in particular really you know you

can see that this expected versus actual

B1 is different from B so you know that

you've got the intermediate context of

this this commute wrong but it certainly

makes um the darks code harder to get

into for newbies it also stops newbies

screwing up the darks code so um that's

that's a sort of two-edged

sword um yeah so that's um and these

contexts can't do everything you do have

to get the lowlevel operations right for

for the sort of stuff around it to make

sense and they don't um in some cases

you actually have to insert a assertions

that say I've thought about this I can't

convince the type Checker that this is

correct but I've thought about it and it

is it is correct and trust me please

um okay so that was just a sort of um

brief overview of all of that um stuff

so what are we going to do with darks

next um well 210 which is the upcoming

release we'll have rebase in it rebase

in it and it will also have a fast rer

take command if you've used dos before

you'd know that the dark annotate

command is one of the things that really

is very slow um and what we've done to

make that a lot better is introduced a

um what's called a patch index a look up

from the

um look up from lines of lines in a file

to what patches touch the line that line

in the file so you can um s Dart can

very quickly find out what patches are

um what patches affected a specific

file yes annotate is yeah

exactly

so what's

the you have V on the same

and yeah so annotate will give you a

different output depending on what order

those patches are in your repository

depends yes yeah so there there are

there are plenty of commands that will

depend on that and changes you know just

the list of changes the annotate um the

way that patches are presented to you

interactively all those things will be

different depending on the order of your

patches um yep so we're um we're

developing a um a bridge to get but it's

not really ready for prime time yet so

we want to um want to get that ready um

we don't have a great hosting story

though we do have um we do have a kind

of on um a standard host for darks

repositories that you can put online and

so forth but it's nowhere near as fully

featured as GitHub so we'd like to

improve that um we'd like to have better

most of interacting with darks is very

text based in fact all of it I mean the

darks command line is just a text tool

there are no standard graphical tools

for it um what we'd like to do is make

something web based that's um kind of

you know the the same the same code base

as the hosting um code that we have just

bring up a web browser locally and allow

you to interact with your repository

like that um but that's still in

progress um we'd love to have multi-head

repositories a bit of implementation

effort um conflict handling is a mess

for a couple of different reasons but

one of which is that we don't actually

have a good algorithm for figuring out

deeply nested conflicts and dealing

making them making them behave properly

and um we hope to improve that in the

future um more patch types that's I mean

that that's kind of the point of darks

right I mean what darks lets you do at

the moment is quite is nice useful and

it's still I I still personally find it

a lot more useable than get but really

we could we could make darks really nice

to use in terms of um you know by having

by having more patch types that let you

do things like moving around chunks of

text from one place to another um make

you know do indent a block of indent a

whole set of lines um by a certain

amount and have those things merge

nicely with other kinds of patches where

that makes

sense

that new is deping on the number of you

already have

so yes that's well it's not it's not

quite that bad because there are some

kinds of patches types that would never

that would never make sense to merge

with each other so for example if you

had a semantic patch that would you know

about um ch um treating a source file as

a pastry and doing stuff with that then

insert a patch that inserts lines in the

middle of that file is never going to

merge with that sensibly I think it we

just say that's a conflict um so you

you're kind of and the the other thing

is that um merging so you know files

that affect the internal contents of a

sorry patches that affect the internal

contents of a file are independent of

patches that say move around the things

in the file system and so on so the yes

you're right basically that that

quadratic explosion does happen will

happen but um there are some mitigating

factors and that but that's part of why

it's difficult to add new patch

types okay so um that was all I had to

say really um if you want to know more

about dos it's got a homepage and it's

got a hosting place um and we are um if

any of you students and interested in

doing some stuff for darks then we are

participating in G in some of code via

um h.org so please apply

[Applause]

um probably four or five some that sort

of um to move to syntax trees other than

um the complexity of the compiler how

conceptually how hard is

that um I don't know how to merge what

what the merge operations on what the

sort of basic patch types for two trees

would be so let's let's say that we've

paused a we've paused a sour file and

we've got a tree and we want to we need

to Define changes to that tree um and

it's not completely obvious to me how

you what those changes should be what

the actual patch Types on trees would be

um so I think that would and then and

given that it's not obvious you're also

going to need to have a good degree of

certainty that you actually that it's

all correct in all cases and so forth so

um probably probably want to bring in a

theor approver or something like that to

um to check it out that's quite hard

some

work

your demo on a single file

is so there are patch types that affect

an entire directory at a time so you can

you know rename a directory and all the

files within that will move and that

will merge and commute nicely with say

adding a new file to that directory on

an independent

Branch two files but if you edited two

files that's two separate patch well I

mean you can stick them together into

the same you know patch with name um you

wouldn't you wouldn't record them as

separate you wouldn't have to record

them as separate patches if I you know

if you if you make a change across your

sourc tree you can the interactive

record will ask you about all those

changes to all the files at once and you

can select some of them to be stuck

together into one patch I said

yes yes and then that will be an atomic

change set that will you know just kind

of BR to the next question which

is

small

um I think it varies quite a bit but um

you know varying from the quick typo fix

and so on which is worth recording as a

separate patch to you know maybe a few

hours work um

or yeah no you would so I

mean so the dark repository itself has

um about 10,000 changes in it and so

well

you know here here's a here's a very

simple one that I made that was just um

fixing a test

um this one looks quite a bit bigger um

that was you know not sure exactly what

it was about but um so you know it's you

you want to group together logically

work that belongs together logically

because otherwise there's not much point

in having Atomic change sets um you you

know you you want to stop being you want

to stop people cherry picking too much

as well you you want to encourage them

to cherry pick things that make sense

and not things that

are yes that's right

yeah how to um how complex is it to do

the transformation

for um not very um it's it's basically a

set of rules for so the the most

interesting cases come in for example

when you're um if you're say merging or

commuting two two hunk patches to you

know individual line changes to the same

file and then you have to make sure that

they it's safe to do it and that you

have to adjust the offsets appropriately

um similarly if you're doing that with

file renames and so forth you need to

make sure that you change the patches

that touch that file um but the the code

for doing that in itself is probably a

few a few pages um you know 00 that sort

of scale

thank you than

you