Thread: [Codestriker-user] Feature request
Brought to you by:
sits
Menu
▾
▴
codestriker-user
|
From: Matthew H. <mat...@wa...> - 2004-02-07 01:02:14
|
David,
=20
The following two concerns have been identified:
=20
1) Developers being able to create topics under a different developer's
e-mail, as well as the rights to delete topics.
- Suggested solution =3D> Add rights related to logging into
CodeStriker
Rights:
Admin Rights:
Delete topics
Add, Edit, Delete, Modify rights of users
=20
Basic Rights (functionality):
Create topics
"Your e-mail address field" will be disabled and
automatically filled in with user login (user e-mail)
=20
<For now we could add users via SQL into the database, but it would be
nice to have a "Users" section to "Add, Edit, Delete, Change rights,
etc.">
=20
2) Multiple differential data for the same CVS file. The scenario came
up that developers need to be able to commit code multiple times to
correlate work with another developer, but be able to save all the
differences that they have made to a particular file over a period of
time before the modifications were reviewed. Other developers would also
be committing their changes, so the differences saved should only
include what the first developer changed. Hopefully the following
example illustrates.
=20
Here is the original file (append.test):
#This is a test
test =3D 0
#To see how to append
append =3D 0
#Differential information from different revisions
diffs =3D 0
#Into one diff file
file =3D 0
=20
A text file contains all the unidiffs that were done on the file prior
to committing the change concatenated together into one file.
Here is the final diff file (append.diff):
=20
Index: append.test
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvs/test/append.test,v
retrieving revision 1.1
diff -u -r1.1 append.test
--- append.test 6 Feb 2004 23:01:29 -0000 1.1
+++ append.test 6 Feb 2004 23:02:32 -0000
@@ -1,7 +1,7 @@
#This is a test
test =3D 0
#To see how to append
-append =3D 0
+append =3D 1
#Differential information from different revisions
diffs =3D 0
#Into one diff file
Index: append.test
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvs/test/append.test,v
retrieving revision 1.2
diff -u -r1.2 append.test
--- append.test 6 Feb 2004 23:03:27 -0000 1.2
+++ append.test 6 Feb 2004 23:03:53 -0000
@@ -3,6 +3,6 @@
#To see how to append
append =3D 1
#Differential information from different revisions
-diffs =3D 0
+diffs =3D 1
#Into one diff file
file =3D 0
Index: append.test
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvs/test/append.test,v
retrieving revision 1.3
diff -u -r1.3 append.test
--- append.test 6 Feb 2004 23:04:49 -0000 1.3
+++ append.test 6 Feb 2004 23:05:06 -0000
@@ -1,5 +1,5 @@
#This is a test
-test =3D 0
+test =3D 1
#To see how to append
append =3D 1
#Differential information from different revisions
Index: append.test
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvs/test/append.test,v
retrieving revision 1.4
diff -u -r1.4 append.test
--- append.test 6 Feb 2004 23:05:27 -0000 1.4
+++ append.test 6 Feb 2004 23:06:27 -0000
@@ -5,4 +5,4 @@
#Differential information from different revisions
diffs =3D 1
#Into one diff file
-file =3D 0
+file =3D 1
=20
When I upload the diff file to CodeStriker, I would like each revision
differential to be contained in its own section. CodeStriker currently
puts all the differentials under the same file notwithstanding the
revision is different.
=20
Anyway, I know this is a handful. Please let me know what you think of
the suggestions and if you'd like any clarifications on what I am
suggesting.
=20
Thanks again for all the help!
=20
Matthew Hailstone
Team Lead - Software UI Department
Waterford Institute
Phone: 801.938.1722=20
=20
*************************************=20
This e-mail may contain privileged or confidential material intended for =
the named recipient only.=20
If you are not the named recipient, delete this message and all =
attachments.=20
Unauthorized reviewing, copying, printing, disclosing, or otherwise =
using information in this e-mail is prohibited.=20
We reserve the right to monitor e-mail sent through our network. =20
*************************************=20
|
|
From: <cod...@sp...> - 2005-07-27 17:20:45
|
It would be nice to have in the config file a value to set the valid open states, so that when I click on List all open topics, it would list all valid open states. To put you in context, I added a state Reviewed so that when a topic is completely reviewed by all reviewers, the topic is set to that state. A mail is automatically sent by codestriker and the Author can commit/discard all comments. Once done, the topic is put in Committed state where the reviewer validate the changes, and finally the Topic is closed. Do you think that feature would be useful to other? As of now, I modified the template to put [0, 3] to display all open topics. Thanks. Marc |
|
From: David S. <si...@us...> - 2005-07-28 02:08:10
|
On Thu, 28 Jul 2005 00:26, cod...@sp... wrote: > It would be nice to have in the config file a value to set the valid > open states, so that when I click on List all open topics, it would > list all valid open states. Have you seen the @readonly_states config variable? In some sense, what you are asking for is the inverse of this. > Do you think that feature would be useful to other? As of now, I > modified the template to put [0, 3] to display all open topics. Maybe you can make the code check if the state is not in @readonly_states, to get the same/similar effect? Failing that - perhaps you could defined a @open_states config variable. -- Cheers, David |
|
From: Marc S. <mar...@gm...> - 2005-07-30 11:23:31
|
As of now, I did a simple modifications in the links for all open topics to push states 0,3. I will look into adding a new variable @open_states. That would be an interesting features. Marc. On 7/28/05, Dan Prince - dp...@In... <+codestriker+jafs+abe3cb3e1a.dprince#Int...@sp...> wrote: > Comments below... >=20 > David Sitsky wrote: > > On Thu, 28 Jul 2005 00:26, cod...@sp... wrote: > > > >>It would be nice to have in the config file a value to set the valid > >>open states, so that when I click on List all open topics, it would > >>list all valid open states. > > > > > > Have you seen the @readonly_states config variable? In some sense, wha= t > > you are asking for is the inverse of this. > > > > > >>Do you think that feature would be useful to other? As of now, I > >>modified the template to put [0, 3] to display all open topics. > > > > > > Maybe you can make the code check if the state is not in @readonly_stat= es, > > to get the same/similar effect? >=20 > This would certainly be possible, but I'm not sure it is what everyone > would want. Some installations (probably ours, for one, though it's > probably not a big deal) would want the 'List open topics' link to list > only topics in state 'open' and not ones in state 'Reviewed', even > though both are not 'read-only' states (i.e. topics in either state can > be edited). >=20 > > > > Failing that - perhaps you could defined a @open_states config variable= . > > >=20 > I would vote for this option. I'm assuming it would control only the > states that get displayed when you click the 'List open states' link, > and would be different from @readonly_states. > |
|
From: David S. <si...@us...> - 2004-02-08 22:34:00
|
Hi Matthew, > 1) Developers being able to create topics under a different developer's > e-mail, as well as the rights to delete topics. > - Suggested solution => Add rights related to logging into > CodeStriker > Rights: > Admin Rights: > Delete topics > Add, Edit, Delete, Modify rights of users > > Basic Rights (functionality): > Create topics > "Your e-mail address field" will be disabled and > automatically filled in with user login (user e-mail) > > <For now we could add users via SQL into the database, but it would be > nice to have a "Users" section to "Add, Edit, Delete, Change rights, > etc."> Yes... I suspect we'll be working on this once we get 1.8.0 out the door, this is something I am very keen to do. 1.8.0 will provide the capability to modify topic attributes, so having some form of security here will be useful, however 1.8.0 will also provide a complete audit trail of how a topic has been changed. We'll have something similar to how Bugzilla manages its users. > 2) Multiple differential data for the same CVS file. The scenario came > up that developers need to be able to commit code multiple times to > correlate work with another developer, but be able to save all the > differences that they have made to a particular file over a period of > time before the modifications were reviewed. Other developers would also > be committing their changes, so the differences saved should only > include what the first developer changed. Hopefully the following > example illustrates. This doesn't make any sense to me! Why can't you "fold" all of the differences together into one diff segment? This is how things are normally done in a Code reviewing situation, or when patch files are generated. Before generating a "cvs diff", you usually need to do a "cvs update -d" to ensure that your working copying is bought uptodate with what is in the repository. This will "merge" all changes together from other authors so that when you do a "cvs diff", all the changes are in one diff segment. I don't think this answers your question... perhaps if you can give a more detailed example from a process perspective as to when you would ever want to generate a diff file with multiple diff segments for the same file. In all cases, they are usually merged together into a single segment, otherwise its more work for the reviewer - they'd want to see all changes for a single file in one place, not in multiple places. -- Cheers, David |
Thanks for helping keep SourceForge clean.
X