Bugzilla – Full Text Bug Listing
| Summary: | [PatchAttached] A faster way to create new repositories | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Martin Aeschlimann <martinae> | ||||||
| Component: | Team | Assignee: | Platform Team Inbox <platform-team-inbox> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | fraenkel, tlroche | ||||||
| Version: | 3.0 | Keywords: | helpwanted | ||||||
| Target Milestone: | 3.1 M7 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Martin Aeschlimann
Another big source of CVS location strings is SourceForge: _every_ project's CVS page gives the commandline that project. It Would Be Nice if the Add CVS Repository wizard could take a location string as input. Created attachment 19267 [details]
Simple patch to accept CVS location
Here is an initial attempt which I don't much like. I was trying to avoid
changing the UI.
1. The password cannot be retrieved
2. Incorporates bad UI style. The CVS location is pulled from the host
information when a : is detected as the first character.
Thanks for the patch. I'll hav a look at it after M6 ships. Created attachment 19272 [details]
Allows host to take a complete CVS string
An alternative way to allow CVS location strings. My original intent was to
allow the host to accept the initial CVS location and the other fields to
override. Without changes to CVSRepositoryLocation you can only change a
subset of the values.
The current patch either uses the host information as the location or combines
the fields to create one.
I think I prefer the first approach if you don't want to change the UI. This approach could support pasting into any of the fileds and not just host. For the second aproach, I think we would need a separate field for the complete string. My feeling is that it will be too confusing without it. Thoughts? Comment #5 From Michael Valenta 2005-03-31 11:29 > I think we would need a separate field for the complete string. My > feeling is that it will be too confusing without it. I concur: I suspect the separate field will also be more usable. The first approach is more usable because it makes it obvious. The password issue would need to be resolved. Also, preventing notification while all the fields are being updated would also be good. The second approach was only done so the password would be used. The issue I had with an extra field was the overall intent. Was it an either or case where you used the new field or the separated fields? Was it specifying an override where the full location is nothing more than a template. I guess it could be a field and a button to apply it to the separate fields. A third approach is just a different page altogether which is just the location for those advanced users. Verified |