Re: [Arx-users] How does tag work?

[Walter Landry]

Kevin Smith <address@hidden> wrote:
> Walter Landry wrote:
> > Kevin Smith <address@hidden> wrote:
> >>Doh! Apparently I'm not allowed to delete that silly ,, file that I 
> >>never wanted in the first place.
> > 
> > Actually, if you had deleted it with "arx rm", or used "rm" before the
> > "init-tree", then it would have worked fine.  The problem is that the
> > init-tree "add"ed it.
> 
> Well, it was init-tree that created it (without my consent). At a 
> minimum, init-tree should probably spit out a message like "I just 
> created ,,2004293523742983 which you can use to enter a log message for 
> the next checkin. If you prefer to use -s, use arx rm ,,200423598234 to 
> get rid of the file.

init-tree created the ,,manifest file as a temp file.  Before it could
delete it, it ran into an exception and bailed.  ArX should really
clean up after itself in such a case.

So I have just implemented that (arx.2.1,106).  Thanks for the bug
report.  This is the sort of thing it is easy for me to miss.

However, I am still curious how you managed to get it to fail that way.

> Well, that's too verbose, but for anyone not already immersed in the 
> arch/arx world, it's all very odd. I would prefer that it not create the 
> file by default.

ArX creates these temp files to reduce the chance of a corrupt tree.
Otherwise, it may run into an error halfway through writing a new
file.  This way, the update to that file either succeeds or fails.

> I would have expected add to ignore ,, files.

ArX assumes that you know what you are doing, and allows you to add
any file you want.

> > Hmm.  I had forgotten how annoying CVS is.  Tags in CVS are used in
> > different ways than in ArX.  In CVS, they are the only way to mark a
> > particular tree-state.  Such a facility is not needed as much in ArX,
> > since every tree state can be retrieved easily.  Tags in ArX are used
> > when you want to have a separate branch that marks only major changes.
> > I believe that is explained in the manual in section 5.9.1.
> 
> Not exactly. Section 5.9.1 describes how to use arx tags as kind of a 
> "promotion" workflow, from sandbox to testing to stable. For my own use, 
> I'm more interested in "tagging" releases with a marketing version 
> number such as 0.1 or 2.5. How can I do that with arx?

With the example you gave, you had a main "waldron" branch, with a
"initial" sub-branch.  If you want to tag a particular revision of
that as v0.0.1, then

  arx tag waldron.initial waldron.initial.v0.0.1

or

  arx tag waldron.initial waldron.v0.0.1

if you don't want the "initial" to be part of the marketing name.  Then

  arx get waldron.v0.0.1

would give you that particular revision of waldron.initial.

> > However, I am planning to coalesce the functionality of tag and config
> > into a single command (fixing bug #10297).  
> 
> Hm. If anything, I would have expected tag to just become a subset of 
> branch. Eclipse's cvs plugin is cool that way--when you tag "1.0" it 
> automatically becomes a branch at the same time.

Right now, a tag is represented in the archive in the same way as a
branch.  Even after I coalesce these things, you can still make a
branch with "fork".  It will be about the same amount of work as the
current version of "tag".

> > Essentially, tag would
> > reduce to the trivial case of a configuration where you only have the
> > main project.  In that case, I might use a completely different
> > command, like "aka", "group", "mark", "consolidate", "combine",
> > "symlink", "pseudonym", or something else (my favorite right now is
> > aka).
> 
> Hm. Tagging (e.g. "0.1") seems like a pretty fundamental operation to 
> me. Assuming there is an easy way to do that, I'm not sure why it would 
> need to be lumped in with a complex feature like config.

It is more like tag would become more powerful.  For simple cases, the
syntax is the same except the order is reversed

  arx aka foo.stable foo.main

If you ran

  arx get foo.stable foo

Then you would get a directory foo containing foo.main.  However, you
can also lump more than one project into it

  arx aka foo.stable foo.main bar.main bar baz.main baz

Then if you ran

  arx get foo.stable foo

you would get a directory structure like this

foo         ----> Contains the project foo.main
foo/bar     ----> Contains the project bar.main
foo/baz     ----> Contains the project baz.main

I have been thinking about the design for a little while, but I have
not yet completely finalized it.  In particular, I am not completely
sold on the way that projects and directories are specified on the
command line.

> Just my outsider perspective...

Keep it up.

Walter