Veracity 2.5 Nightly Builds

[Ian Olsen]

The final release of Veracity 2.5 is just a few weeks away! In 2.5 we
rewrote the working copy layer for improved performance and stability.
We've been using it for months, and it's ready for feedback.

Nightly builds are now available, if you'd like an early look:
http://download.sourcegear.com/Veracity/nightly/

Please commit any changes before upgrading, as you'll have to check out
a fresh working copy to work with 2.5.

[Pau Garcia i Quiles]

Post by Ian Olsen
The final release of Veracity 2.5 is just a few weeks away! In 2.5 we
rewrote the working copy layer for improved performance and stability.
We've been using it for months, and it's ready for feedback.
http://download.sourcegear.**com/Veracity/nightly/<http://download.sourcegear.com/Veracity/nightly/>

Is it possible to build this version without patched third-parties?

[Ian Olsen]

Post by Pau Garcia i Quiles
Is it possible to build this version without patched third-parties?

Yes it is! On Debian/Ubuntu, Veracity 2.5 depends on the libmozjs185-1.0
package rather than the older, patched version of SpiderMonkey. (You'll
need libmozjs185-dev to build.)

--
Ian

[Pau Garcia i Quiles]

Post by Ian Olsen

Post by Pau Garcia i Quiles
Is it possible to build this version without patched third-parties?

Yes it is! On Debian/Ubuntu, Veracity 2.5 depends on the libmozjs185-1.0
package rather than the older, patched version of SpiderMonkey. (You'll
need libmozjs185-dev to build.)

That's indeed great news: it means I can finally package Veracity for
Debian.

Why does Veracity still require patched third-parties on Windows and Mac?
(or at least that's what it looks like from the sources)

[Paul Egli]

Post by Pau Garcia i Quiles
Why does Veracity still require patched third-parties on Windows and
Mac? (or at least that's what it looks like from the sources)

We use scripts to build the libraries on those systems since they don't
have a standard distribution system like apt-get. Any patches are just
so that they compile on the given platform without any warnings.

[ST]

Post by Pau Garcia i Quiles
Is it possible to build this version without patched
third-parties?
Yes it is! On Debian/Ubuntu, Veracity 2.5 depends on the
libmozjs185-1.0 package rather than the older, patched version
of SpiderMonkey. (You'll need libmozjs185-dev to build.)
That's indeed great news: it means I can finally package Veracity for
Debian.

Will it be able to get into sid? When is there the next freeze?

ST

[Pau Garcia i Quiles]

Post by ST

Post by Pau Garcia i Quiles
Is it possible to build this version without patched
third-parties?
Yes it is! On Debian/Ubuntu, Veracity 2.5 depends on the
libmozjs185-1.0 package rather than the older, patched version
of SpiderMonkey. (You'll need libmozjs185-dev to build.)
That's indeed great news: it means I can finally package Veracity for
Debian.

Will it be able to get into sid? When is there the next freeze?

Unfortunately, Sid is already frozen (it's been for months).

I will make the packages available for Debian from my OpenSuse Build
Service repository and for Ubuntu from my PPA, though.

[Jace Browning]

What changes should we focus on during the beta testing?

Post by Ian Olsen
The final release of Veracity 2.5 is just a few weeks away! In 2.5 we
rewrote the working copy layer for improved performance and stability.
We've been using it for months, and it's ready for feedback.
http://download.sourcegear.**com/Veracity/nightly/<http://download.sourcegear.com/Veracity/nightly/>
Please commit any changes before upgrading, as you'll have to check out a
fresh working copy to work with 2.5.
--
Ian Olsen
Veracity Project Manager
______________________________**_________________
Veracity-users mailing list
http://lists.sourcegear.com/**cgi-bin/mailman/listinfo/**veracity-users<http://lists.sourcegear.com/cgi-bin/mailman/listinfo/veracity-users>

[Ian Olsen]

The big change in 2.5 is the working copy code, which also meant fairly
substantial changes to the tortoise interface on Windows. Those are the
two areas we're most interested in.

Post by Jace Browning
What changes should we focus on during the beta testing?
The final release of Veracity 2.5 is just a few weeks away! In 2.5
we rewrote the working copy layer for improved performance and
stability. We've been using it for months, and it's ready for feedback.

[Jace Browning]

I am getting an error attempting to view the status against an earlier tag:

$ vv version
2.5.0.11040 (f130254375) [64-bit WINDOWS]

$ vv status --tag 00.02.000
Error: Not implemented.

Post by Ian Olsen
The big change in 2.5 is the working copy code, which also meant fairly
substantial changes to the tortoise interface on Windows. Those are the two
areas we're most interested in.

Post by Jace Browning
What changes should we focus on during the beta testing?
The final release of Veracity 2.5 is just a few weeks away! In 2.5
we rewrote the working copy layer for improved performance and
stability. We've been using it for months, and it's ready for feedback.

[Ian Olsen]

Thanks for the report, Jace.

That's actually a known issue: status with a single revision given was
JUST implemented. It's in the nightlies starting Friday night, which was
11045.

Post by Jace Browning
$ vv version
2.5.0.11040 (f130254375) [64-bit WINDOWS]
$ vv status --tag 00.02.000
Error: Not implemented.

[Ian Olsen]

Hi Jace. (I've cc'ed the mailing list.)

We thought we picked sensible defaults, but many users were confused
about the state of their branch attachment when updating by revision.

In 2.1 (and older):

update -b <branch>
------------------
Updates to the head of <branch> and attaches to it. Always.

update -r 10
------------
Updates to revision 10 and always preserves your current attachment,
even if revision 10 is the head of a different branch or not a branch
head at all. This confused people. Often they'd inadvertently commit
changes against the wrong branch.

In 2.5:

update -b <branch>
------------------
Updates to the head of <branch> and attaches to it. Always. (No change.)

update -r 10
------------
If revision 10 is the head of (exactly one) branch, update to it and
attach to its branch. If revision 10 is NOT the head of exactly one
branch, make the user be explicit about their intentions with either
--detached or --attach <existing-branch>, or --attach-new
<non-existing-branch>.

Can you explain the justification for the Veracity 2.5 change that can
$ vv update -r 3d7
Error: The proper branch cannot be determined automatically; please use
one of the attach or detached options: The
target changeset '3d7fd7ac667de193f31455d80113a0ca26b314b0' is not a
head; you must explicitly attach/detach the WD
It is rather annoying that I can't easily jump back to an earlier
version without adding more command line args...

[Jace Browning]

I agree with your decision to prevent people from committing to the wrong
branch, but if I have this DAG:

5 (master)
|
| 4 (feature_x)
| |
2 3
|/
1
|
0

And I `vv update -r 3` why not attach my working copy to 'feature_x'? What
else could I mean?

Post by Ian Olsen
Hi Jace. (I've cc'ed the mailing list.)
We thought we picked sensible defaults, but many users were confused about
the state of their branch attachment when updating by revision.
update -b <branch>
------------------
Updates to the head of <branch> and attaches to it. Always.
update -r 10
------------
Updates to revision 10 and always preserves your current attachment, even
if revision 10 is the head of a different branch or not a branch head at
all. This confused people. Often they'd inadvertently commit changes
against the wrong branch.
update -b <branch>
------------------
Updates to the head of <branch> and attaches to it. Always. (No change.)
update -r 10
------------
If revision 10 is the head of (exactly one) branch, update to it and
attach to its branch. If revision 10 is NOT the head of exactly one branch,
make the user be explicit about their intentions with either --detached or
--attach <existing-branch>, or --attach-new <non-existing-branch>.

Can you explain the justification for the Veracity 2.5 change that can
$ vv update -r 3d7
Error: The proper branch cannot be determined automatically; please use
one of the attach or detached options: The
target changeset '**3d7fd7ac667de193f31455d80113a0**ca26b314b0' is not a
head; you must explicitly attach/detach the WD
It is rather annoying that I can't easily jump back to an earlier
version without adding more command line args...