You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Robert P. J. Day" <rp...@mindspring.com> on 2005/01/15 13:53:33 UTC
[OT] interested in subversion-friendly project management SW
in addition to using svn strictly for version control, i'm
interested in migrating to other management tools that work well with
subversion.
as a start, a wiki, and i can see that there is a "subwiki" project
at tigris, so i'll be looking into that shortly.
in addition, an issue tracker and, again, i see "scarab" so i'll
poke around there as well.
as a general question, is anyone using an entire set of svn-related
software to handle all (or many) aspects of project management? how
well does it work? and where should i really be asking questions like
this? :-)
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by Kevin Williams <ke...@bantamtech.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You might want to check out Trac (http://projects.edgewall.com/trac).
It's a wiki with svn browsing and bug tracking. I find it excellent for
project-based sites.
Robert P. J. Day wrote:
| in addition to using svn strictly for version control, i'm
| interested in migrating to other management tools that work well with
| subversion.
|
| as a start, a wiki, and i can see that there is a "subwiki" project
| at tigris, so i'll be looking into that shortly.
|
| in addition, an issue tracker and, again, i see "scarab" so i'll
| poke around there as well.
|
| as a general question, is anyone using an entire set of svn-related
| software to handle all (or many) aspects of project management? how
| well does it work? and where should i really be asking questions like
| this? :-)
|
| rday
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
| For additional commands, e-mail: users-help@subversion.tigris.org
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB6nE+PUUiO/wZktQRAp2PAJ9uiXdBwX1oV1t63YBaLxjLMAuFwgCfWCu8
sZSEqbgi8EMWZQar29sHmrU=
=ro/G
-----END PGP SIGNATURE-----
----------
Scanned for viruses by ClamAV
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by PA <pe...@gmail.com>.
On Jan 16, 2005, at 05:50, Paul DeMarco wrote:
> ok, so a bit of a sales pitch
I will add my voice to the sale pitch as well: Trac is very nifty :)
Plus it looks great too:
"Code Browser"
http://www.edgewall.com/gfx/screenshots/log.png
"Changeset Viewer"
http://www.edgewall.com/gfx/screenshots/changeset.png
Cheers
--
PA
http://alt.textdrive.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by Paul DeMarco <pa...@pauldemarco.com>.
Trac (http://projects.edgewall.com/trac) works really well, and not to
limit it off the bat, but i think it works best in smaller teams (<20),
that require minimal overhead but complete tracking, it has:
* issue tracking
* explicit svn integration
* built in wiki
* search ability, custom ticket properties, notification
* rss feeds for events
* a pretty customizable query and sql based (aka flexible) reporting engine
* to boot, its got a nice UI as well
ok, so a bit of a sales pitch
--paul
Robert P. J. Day wrote:
> in addition to using svn strictly for version control, i'm
>interested in migrating to other management tools that work well with
>subversion.
>
> as a start, a wiki, and i can see that there is a "subwiki" project
>at tigris, so i'll be looking into that shortly.
>
> in addition, an issue tracker and, again, i see "scarab" so i'll
>poke around there as well.
>
> as a general question, is anyone using an entire set of svn-related
>software to handle all (or many) aspects of project management? how
>well does it work? and where should i really be asking questions like
>this? :-)
>
>rday
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by Steve Williams <st...@kromestudios.com>.
Check out Trac
http://projects.edgewall.com/trac/
Sly
> in addition to using svn strictly for version control, i'm
> interested in migrating to other management tools that work well with
> subversion.
>
> as a start, a wiki, and i can see that there is a "subwiki" project
> at tigris, so i'll be looking into that shortly.
>
> in addition, an issue tracker and, again, i see "scarab" so i'll
> poke around there as well.
>
> as a general question, is anyone using an entire set of svn-related
> software to handle all (or many) aspects of project management? how
> well does it work? and where should i really be asking questions like
> this? :-)
>
> rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by Mark Bohlman <mb...@tcicredit.com>.
Peter Valdemar Mørch wrote:
> Nick_Gianakas@sybari.com wrote:
>
>> I think practically every issue tracker has this capability. Branches
>> worth keeping track of are typically releases. If configured, the
>> issue tracker supports one or more releases for a particular issue.
>> So branch X is probably version 1.X, which could have an entry in the
>> issue tracker.
>
>
> Yes. And no.
>
> I can fiddle with the tool and manually decide that it applies to
> releases X, Y and Z.
>
> Now it gets fixed, verified and closed in release X. (But is still
> unfixed in Y and Z). At least in the tools I know of, I can not get it
> to show that it originally applied to releases X, Y and Z, but is fixed
> in X only. The tools I've seen only support listing which releases the
> current bug state applies to, so history is lost.
>
> Also, assume the fix is in rev. 4000 on branch REL_X.
>
> Now a merge like:
>
> svn merge -r 3900:4100 $repos/branches/REL_X .
>
> is done and comitted in a REL_Y working copy.
>
> Therefore, this bug got fixed in branch Y, and needs verification on
> branch Y. This bugfix should be automatically detected!!! Why should a
> human have to do that? Sure, it needs verification: "Does the merged
> functionality actually work on the new branch?" But that goes for all
> merge modifications. The bug should automatically get marked as fixed
> but not verified on branch Y.
>
> Now, the bug is Fixed, verified and closed on branch X, fixed but not
> verified on branch Y and unfixed on branch Z.
>
> What tool can track this real-life behavior? And why aren't others
> wanting this, I wonder most of all...
>
> Peter
>
Actually, there was a tool written that would, if I recall correctly, do
exactly what you want. But it was designed specifically (originally)
for the Ingres database development effort and to my knowledge has never
been made publicly available anywhere. Which is sad, because those that
used it really liked the power it provided. It tracked changes across
platforms, branches and versions allowing rapid porting of code to the
multitude of environments Ingres was offered on.
-- Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Commit failed
Posted by Peter Bruin <pe...@boschman.com.sg>.
I get the following error while performing a commit.
Transmitting file data .......svn: Commit failed (details follow):
svn: Can't remove 'C:/repos/sw/db/transactions/99-1.txn': The process cannot
access the file because it is being used by another process.
But when I check there are no transactions left in this directory. What
could cause the problem?
Also it is not possible to continue with the branch that was checked out. I
can not do an update:
>Svn update
G os2\col_dlv.cmd
svn: Failed to add directory 'os2/MMI/DDIR': object of the same name already
exists
I tried doing a svn revert -R *.* that outputs that it has reverted the
directory.
However, if I try to do svn up it will prompt the same as before.
The only way I manage to continue is to delete everything and checkout a
fresh copy.
Does anybody have similar experience?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by Jamie Lawrence <ja...@jal.org>.
On Tue, 18 Jan 2005, Sean Laurent wrote:
> Mantis (http://www.mantisbt.org) provides the closest to this I've seen in a
> while.
>
> You can create a clone of an issue and tie the two issues together with a
> dependency relationship ("related to", "depends on", "prereq of", etc.):
>
> - Create a general issue for the bug (let's say issue #42)
> - Create a clone (#43) that's a child of #42. In other words, #43 blocks #42
> until #43 is marked as complete. Make #43 for release X.
> - Create another clone (#44) that's a child of #42 and make it for release Y.
RT (http://www.bestpractical.com/rt/) can do this as well, and also
supports making a tree of dependent bugs something that needs "approval"
- a signoff step.
RT is also eminently hackable (mod_perl/Mason, with a fairly clean
indirection layer for customizing through upgrades), if you're in to that
sort of thing.
-j
--
Jamie Lawrence jal@jal.org
Any reviewer who expresses rage and loathing for a novel is preposterous.
He or she is like a person who has put on full armor and attacked a hot
fudge sundae.
- Kurt Vonnegut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by Mark Bohlman <mb...@tcicredit.com>.
Sean Laurent wrote:
> On Tuesday 18 January 2005 01:45 pm, Nick_Gianakas@sybari.com wrote:
>
>>A nice feature here would be to have an issue split itself (emulate
>>multiple copies) per attribute (platform, release, etc). That's probably
>>what you're looking for. I don't know of an issue tracker that does this.
>
>
> Mantis (http://www.mantisbt.org) provides the closest to this I've seen in a
> while.
>
> You can create a clone of an issue and tie the two issues together with a
> dependency relationship ("related to", "depends on", "prereq of", etc.):
>
> - Create a general issue for the bug (let's say issue #42)
> - Create a clone (#43) that's a child of #42. In other words, #43 blocks #42
> until #43 is marked as complete. Make #43 for release X.
> - Create another clone (#44) that's a child of #42 and make it for release Y.
>
> Now, Peter Valdemar Mørch originally requested:
>
>>- "I know bug # X has been fixed on branch Y. But has
>>it been fixed on branch Z? Was it ever present on branch Z?"
>>
>>- A tool that can keep track of what branches the bug applies to / is
>>relevant for, and what branches it has been fixed on - either because
>>it has been manually fixed on several branches, or because the fix
>>has been merged from one branch to another.
>
>
> Unfortunately, Mantis doesn't help with this at all.
>
> However, Pete also wrote:
>
>
>>At least in the tools I know of, I can not get it to show that it
>>originally applied to releases X, Y and Z, but is fixed in X only.
>
>
> If you're willing to do the manual work of outlining which releases you ~know~
> contain the bug, then my aforementioned solution in Mantis might work for
> you. I would guess other bug tracking packages provide similar
> functionality, so you might be able to adapt that strategy and at least
> improve your issue tracking a little bit.
>
> -Sean
The Ingres system was integrated with the issue tracker and so did
indeed maintain open issues per "variant". Sigh, if only we could prise
it free from the current owners.....
-- Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by Sean Laurent <se...@neuronfarm.com>.
On Tuesday 18 January 2005 01:45 pm, Nick_Gianakas@sybari.com wrote:
> A nice feature here would be to have an issue split itself (emulate
> multiple copies) per attribute (platform, release, etc). That's probably
> what you're looking for. I don't know of an issue tracker that does this.
Mantis (http://www.mantisbt.org) provides the closest to this I've seen in a
while.
You can create a clone of an issue and tie the two issues together with a
dependency relationship ("related to", "depends on", "prereq of", etc.):
- Create a general issue for the bug (let's say issue #42)
- Create a clone (#43) that's a child of #42. In other words, #43 blocks #42
until #43 is marked as complete. Make #43 for release X.
- Create another clone (#44) that's a child of #42 and make it for release Y.
Now, Peter Valdemar Mørch originally requested:
>- "I know bug # X has been fixed on branch Y. But has
> it been fixed on branch Z? Was it ever present on branch Z?"
>
>- A tool that can keep track of what branches the bug applies to / is
> relevant for, and what branches it has been fixed on - either because
> it has been manually fixed on several branches, or because the fix
> has been merged from one branch to another.
Unfortunately, Mantis doesn't help with this at all.
However, Pete also wrote:
> At least in the tools I know of, I can not get it to show that it
> originally applied to releases X, Y and Z, but is fixed in X only.
If you're willing to do the manual work of outlining which releases you ~know~
contain the bug, then my aforementioned solution in Mantis might work for
you. I would guess other bug tracking packages provide similar
functionality, so you might be able to adapt that strategy and at least
improve your issue tracking a little bit.
-Sean
------------------------------
Ingrate, n.: A man who bites the hand that feeds him, and then complains of
indigestion.
------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by Ni...@sybari.com.
> I can fiddle with the tool and manually decide that it applies to
> releases X, Y and Z.
>
> Now it gets fixed, verified and closed in release X. (But is still
> unfixed in Y and Z). At least in the tools I know of, I can not get it
> to show that it originally applied to releases X, Y and Z, but is fixed
> in X only. The tools I've seen only support listing which releases the
> current bug state applies to, so history is lost.
I see what you're saying. But the problem could be in the usage of the
issue tracker. If an issue is open that is confirmed in releases X, Y,
and Z, then the issue probably should not be marked as fixed or closed
until it has actually been fixed in all releases. Doing otherwise is no
different than marking an issue as fixed after correcting it for Win2000
but ignoring WinXP (just an example).
If independent control over the issue is desired (per release), then open
an issue for each release. This has the downside of no
inter-communication.
A nice feature here would be to have an issue split itself (emulate
multiple copies) per attribute (platform, release, etc). That's probably
what you're looking for. I don't know of an issue tracker that does this.
Regards,
Nick G.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by Peter Valdemar Mørch <no...@morch.com>.
Nick_Gianakas@sybari.com wrote:
> I think practically every issue tracker has this capability. Branches
> worth keeping track of are typically releases. If configured, the issue
> tracker supports one or more releases for a particular issue. So branch X
> is probably version 1.X, which could have an entry in the issue tracker.
Yes. And no.
I can fiddle with the tool and manually decide that it applies to
releases X, Y and Z.
Now it gets fixed, verified and closed in release X. (But is still
unfixed in Y and Z). At least in the tools I know of, I can not get it
to show that it originally applied to releases X, Y and Z, but is fixed
in X only. The tools I've seen only support listing which releases the
current bug state applies to, so history is lost.
Also, assume the fix is in rev. 4000 on branch REL_X.
Now a merge like:
svn merge -r 3900:4100 $repos/branches/REL_X .
is done and comitted in a REL_Y working copy.
Therefore, this bug got fixed in branch Y, and needs verification on
branch Y. This bugfix should be automatically detected!!! Why should a
human have to do that? Sure, it needs verification: "Does the merged
functionality actually work on the new branch?" But that goes for all
merge modifications. The bug should automatically get marked as fixed
but not verified on branch Y.
Now, the bug is Fixed, verified and closed on branch X, fixed but not
verified on branch Y and unfixed on branch Z.
What tool can track this real-life behavior? And why aren't others
wanting this, I wonder most of all...
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by Ni...@sybari.com.
> "I know bug # X has been fixed on branch Y. But has it been fixed on
> branch Z? Was it ever present on branch Z?"
>
> - A tool that can keep track of what branches the bug applies to / is
> relevant for, and what branches it has been fixed on - either because it
> has been manually fixed on several branches, or because the fix has been
> merged from one branch to another.
>
> I always wonder how a bug tracking tool can have one state variable e.g.
> with values from (New,Assigned,Fixed) and still usefully reflect reality
> in the presence of branches.
>
> Does anyone know of a tool that can track *that*?
I think practically every issue tracker has this capability. Branches
worth keeping track of are typically releases. If configured, the issue
tracker supports one or more releases for a particular issue. So branch X
is probably version 1.X, which could have an entry in the issue tracker.
Regards,
Nick G.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [OT] interested in subversion-friendly project management SW
Posted by Peter Valdemar Mørch <no...@morch.com>.
Hi there,
I have always been wondering why no tool that I know of can help me
answer this question:
"I know bug # X has been fixed on branch Y. But has it been fixed on
branch Z? Was it ever present on branch Z?"
- A tool that can keep track of what branches the bug applies to / is
relevant for, and what branches it has been fixed on - either because it
has been manually fixed on several branches, or because the fix has been
merged from one branch to another.
I always wonder how a bug tracking tool can have one state variable e.g.
with values from (New,Assigned,Fixed) and still usefully reflect reality
in the presence of branches.
Does anyone know of a tool that can track *that*?
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org