Re: [Gnu-arch-users] Moving directories to a new branches tree-root (tree root id?)

[Ben Burns]

On Monday 05 April 2004 12:24, Jan Hudec wrote:
> On Sun, Apr 04, 2004 at 12:15:22 +0200, Ben Burns wrote:
> > On Sunday 04 April 2004 10:49, Jan Hudec wrote:
> > > On Sat, Apr 03, 2004 at 16:28:50 +0200, Ben Burns wrote:
> > > > Hi,
> > > >
> > > > I wanted to find out if the tree root can have an arch id tag like
> > > > any other file and directory in the source tree. I have heard arch
> > > > does not use it. If not, how can arch know that a downstream source
> > > > has moved a directory to the tree-root? So that any file or directory
> > > > added to the upstream directory would be included in merges in the
> > > > downstream's tree root.
> > > >
> > > > If so, how can you do it,
> > > >     # tla mv some/dir .
> > > > obviously wouldn't work (will create dir in the tree root), whereas
> > > >     # tla mv some/dir/* .
> > > > will drop upstream additions to dir.
> > > >
> > > > On the otherhand
> > > >     # tla add .
> > > > does seem to work.
> > > >
> > > > I would think that being able move id tagged directories to the root
> > > > would be useful for splitting large upstream trees into smaller ones
> > > > buildable with configs.
> > >
> > > There is exactly one tree root in a branch. Thus it can't be moved and
> > > does not need (nor use) tag. If you mv some/dir/* . you move each file
> > > in some/dir to ., not some/dir itself.
> > >
> > > If you split large tree to configs, each subtree is _completely
> > > separate_ from arch's point of view. You can't move files between them
> > > -- they will be removed from one and added in the other.
> > >
> > > tla add . works simply because it's quite simple-minded.
> > >
> > > > P.S: This didn't get sent yesterday, so I had a chance to think this
> > > > through a little more. I think the proper way to split a large tree
> > > > into a smaller one would be to branch the current tree, init-tree in
> > > > the directory you want using the new branch and make-sync-tree with
> > > > the new branch. Committing the resulting branch should make the new
> > > > version updateable (starmergable?) from the big tree without errors.
> > > > Syncing the big tree with this revision should mean the big tree can
> > > > starmerge future patches from the small tree too.
> > > >
> > > > So, does arch use the id in the tree-root if it exists? Will this
> > > > work? Some at #arch didn't seem to think so.
> > >
> > > The tree-root is not part of the branch. It's container for the
> > > checked-out tree. Arch won't (and shouldn't) ever look at it's id.
> > >
> > > However, what you described above should work as expected -- just
> > > attributes for the directory won't be recorded. But since files will be
> > > matched by tags no matter what directory they are in, patches will find
> > > the right place to apply to.
> >
> > This is what I doubt, let me give an example:
> > split--bigtree--0:
> >     .
> >     + --- a/aA/aA.txt
> >     + --- a/aB/aB.txt
> >     + --- b/bA/bA.txt
> >     + --- b/bB/bB.txt
> >
> > in directories 'a', and 'b' we do tag, init-tree, sync tree, commit to
> > give us:
> > split--a-project--0:
> >     . (id matches bigtree a)
> >     + ---   aA/aA.txt
> >     + ---   aB/aB.txt
> > and,
> > split--b-project--0:
> >     . (id matches bigtree b)
> >     + ---   bA/bA.txt
> >     + ---   bB/bB.txt
> >
> > then in bigtree we commit a patch that changes the tree to:
> >     .
> >     + --- a/aA/aA.txt
> >     + --- a/aC/aC.txt
> >     + --- a/aB/aB.txt [added]
> >     + --- b/bA/bA.txt
> >     + --- b/bB/bB.txt
> >     + --- b/bC/bC.txt [added]
> >
> > so, when we then do a subsequent star-merge from bigtree to a-project and
> > b-project, I would expect to have:
> > split--a-project--0:
> >     .
> >     + ---   aA/aA.txt
> >     + ---   aB/aB.txt
> >     + ---   aC/aC.txt [added]
> >
> > split--b-project--0:
> >     .
> >     + ---   aA/aA.txt
> >     + ---   aB/aB.txt
> >     + ---   aC/aC.txt [added]
>
> No. Both files must get added to both trees!
ooops, this was a typo it was meant to be:
split--b-project--0:
        .
        + --- bA/bA.txt
        + --- bB/bB.txt
        + --- bC/bC.txt
>
> > in, fact, when I star-merge bigtree into a-project, what I actually get
> > is split--a-project--0:
> >     .
> >     + --- a/aC/aC.txt [added to wrong directory]
>
> In the patchset, the mapping is tag to full path, not tag to name and
> parent tag.
Okay, so I think this is a problem...

>
> >     + --- aA/aA.txt
> >     + --- aB/aB.txt
> >     + --- b/bC/bC.txt [added incorrectly]
>
> Added correctly. How did you explain to it, that is should NOT add the
> file? It is in the changeset.

>
> > if I do an update to split--a-project--0 from bigtree, I get no changes
> > except for the addition of the patchlog.
> >
> > The odd thing is that the id of the a directory in the bigtree is the
> > same as the id of the tree-root of the a-project, and I think the reason
> > this is not working is that arch is treating the tree-root specially as
> > regards to its id.  I don't unsertand why it should be treated
> > differently.
>
> It does NOT treat the tree-root AT ALL. The tree-root is NOT a part of
> the source, but a container for it.

Okay, so I understand that arch does not currently look at the tree-root at 
all.  I will argue though that it should, as well as looking at parent 
directory id's.

First of all, lets assume that bigtree is a largish project that someone else 
maintains that may contain a subproject (neatly stored in a directory) I am 
interested in.  I may have no ability to influence the contents or 
development of bigtree, and we can assume that development just continues on 
that branch.

Right now, if I create my own sub-project from bigtree as described above, 
lets look at the type of things arch currently can do to help me track 
changes to the bigtree in the subproject I am working on.

Private file changes: I can make changes in my subproject branch, and continue 
to merge changes in those files in from the bigtree without problem 
(conflicts aside).  So, I can maintain local file changes.

File Renames/Moves: I can rename files in the subproject, and changes to those 
files in the bigtree can be star-merged into my subproject's files with no 
problem.

Delete Files: I can delete files from my subproject tree, and updates to 
missing files are not applied to my source tree.

Add Files: I can of course add files to subproject and unless a file with the 
pathname is added to bigtree I won't get conflicts.

Here's what I cannot do:
I can NOT easily merge changesets from the bigtree into my subproject that 
contain files added to directories I have moved!!  Directories and files end 
up in the (from my perspective) wrong directory. (original path in bigtree?).

Which means I cannot move directories and reorganise my tree if I expect files 
to be added to the parent tree.  Which also means I cannot easily split an 
upstream project into smaller branches (buildable with a config) and continue 
to track changes in the upstream. 

I think that added files and directories should be placed in the directory 
with the same id as the directory into which they were added in the upstream 
branch.  This obviously means looking at the id of parent directories (and by 
extention, the tree-root id).

Is there any reason arch couldn't work this way?

Cheers,
Ben