Monticello and branching

Hi,

today I wanted to branch my app. While saving a new version
I just changed name from App-noha.number to AppBeta-noha.number
thinking there is some magic in Monticello. To be honest I had
no other idea. I think the Package should stay the same.
But those files aren't treated special, right? If I try to
figure out the newest version of my branch I have to parse
all the file infos myself, right? Or did I misunderstand the
way branching is done.

thanks in advance,

Norbert

2007/5/2, Norbert Hartl <[hidden email]>:
Every commit is a branch. Filename hackery is very tricky and almost
guaranteed to break some parts of the UI. Just give the commit a
unique number and you're done.

Cheers
Philippe

> thanks in advance,
>
> Norbert
>
>
>

On Wed, 2007-05-02 at 20:54 +0200, Philippe Marschall wrote: I don't agree. As long as your are the only developer there is a linear
progress indicated by the file number. Ok, you can choose filenames on
your onw but I recurr on the filename Monticello provides you. The next
thing which comes near to a branch is a second developer. There you have
two different lines of development. This isn't indicated by filenames
but on what developers do. If you merge two versions you merge the
"branch". Choosing a different filename prefix you create a second entry
in the Monticello browser. It is shown in the left pane as a separate
entry. This is what I would recognize as a different development line.
So Monticello provides numbers to differ one file from each other. This
is useful information even if you can't take this as a reliable version
information. About file hackery: While Monticelle shows different
prefixes as different things it does filename hackery itself. So why
does the UI differ things which the code below doesn't??

But I take this as an answer that I have to parse it myself ;)

Norbert

Filename hell with Monticello occurs when one developer copies a
repository to another computer, creates two separate branches of
functionality on both computers (the original and the copy).
Monticello chooses the same filenames for the very different invidual
packages, causing merging to be virtually impossible or, at least,
very painful.

If Monticello would include the UUID in the filename, that might solve it..


On 5/2/07, Philippe Marschall <[hidden email]> wrote:

On Wed, 2007-05-02 at 21:00 -0400, Chris Muller wrote:
> Filename hell with Monticello occurs when one developer copies a
> repository to another computer, creates two separate branches of
> functionality on both computers (the original and the copy).
> Monticello chooses the same filenames for the very different invidual
> packages, causing merging to be virtually impossible or, at least,
> very painful.
>
Ok, but copying a repository and edit it simultanously always conflicts.
My concern where based on the "branch" you can do with renaming the
file. I just recognized that there is only a package and this is stored
in a repository. It doesn't matter which filename those commits have
but Monticello Browser gives you separate view.

> If Monticello would include the UUID in the filename, that might solve it..
>
That would be a long filename ;)

Norbert

I think I understand you.  The *contents* of the files are where all
the meat of the package is, not in the filename itself.

This is true with one exception:  When merging, Monticello looks for
the ancestor of a package based on its ancestor's filename embedded in
the package, which is why the (very common) scenario I mentioned, the
same developer creating two branches off the same version in different
repositories, is a major pain.

I can understand why Monticello does this, it assumes the files are
never renamed.  But they sometimes need to be, as in the above
scenario.  Which is why I suggest that packages be named with their
UUID as one node of the filename; it would seem to alleviate the
problem completely.

> That would be a long filename ;)

But that's no problem though, right?  OS's today can handle 200+
character filenames..

 - Chris

On 5/3/07, Norbert Hartl <[hidden email]> wrote:

Chris Muller a écrit :
>
>> That would be a long filename ;)
>
> But that's no problem though, right?  OS's today can handle 200+
> character filenames..
>
> - Chris
>

Beware, some tools might be limited.
I remember of some tar imposing limitations stricter than OS.

nicolas