Hi,
Since most of the Geany plugins were moved to the 'central' plugin repository, I'd like to suggest to add the plugin name onto the commit message in the first line. This would make it much easier for somebody that is looking for a special commit than to have something like this:
r101: Compilation fixes r102: Compilation fixes r103: Compilation fixes r104: Compilation fixes
With the prefix there would be something like that:
r101: Plugin A: Compilation fixes r102: Plugin B: Compilation fixes r103: Plugin C: Compilation fixes r104: Plugin D: Compilation fixes
Opinions?
Cheers, Frank
On Fri, 20 Jun 2008 11:43:50 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
Hi,
Since most of the Geany plugins were moved to the 'central' plugin repository, I'd like to suggest to add the plugin name onto the commit message in the first line. This would make it much easier for somebody that is looking for a special commit than to have something like this:
r101: Compilation fixes r102: Compilation fixes r103: Compilation fixes r104: Compilation fixes
With the prefix there would be something like that:
r101: Plugin A: Compilation fixes r102: Plugin B: Compilation fixes r103: Plugin C: Compilation fixes r104: Plugin D: Compilation fixes
Opinions?
Well, it would be quite annoying to have to type the plugin name each time. If someone was looking for a commit for a specific plugin, wouldn't they just use 'svn log plugindir' rather than for the whole trunk?
Regards, Nick
On Fri, June 20, 2008 2:00 pm, Nick Treleaven wrote:
On Fri, 20 Jun 2008 11:43:50 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
Hi,
Since most of the Geany plugins were moved to the 'central' plugin repository, I'd like to suggest to add the plugin name onto the commit message in the first line. This would make it much easier for somebody that is looking for a special commit than to have something like this:
r101: Compilation fixes r102: Compilation fixes r103: Compilation fixes r104: Compilation fixes
With the prefix there would be something like that:
r101: Plugin A: Compilation fixes r102: Plugin B: Compilation fixes r103: Plugin C: Compilation fixes r104: Plugin D: Compilation fixes
Opinions?
Well, it would be quite annoying to have to type the plugin name each time. If someone was looking for a commit for a specific plugin, wouldn't they just use 'svn log plugindir' rather than for the whole trunk?
I think it's not a big deal to add these lines and give some more overview, e.g. if you working with git as frontend for geany-plugin.
Frank
On Fri, 20 Jun 2008 14:30:13 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
I think it's not a big deal to add these lines and give some more overview, e.g. if you working with git as frontend for geany-plugin.
Can you explain more about this? How does it work?
Regards, Nick
Hi,
On Fri, June 20, 2008 2:39 pm, Nick Treleaven wrote:
On Fri, 20 Jun 2008 14:30:13 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
I think it's not a big deal to add these lines and give some more overview, e.g. if you working with git as frontend for geany-plugin.
Can you explain more about this? How does it work?
I'm using git-svn instead of svn for working with the geany-plugin repository. It combines the advantages of git (branching, fast, local copy of complete history) with the given svn repository. Because of this it feels like a normal git repository, but with the chance to commit to the central svn repository.
Checkout is possible by git-svn clone http://path.to.svn.repo
Also it is possible to set up that it can handle the tags and branches created in svn by using options and a couple of ore things. There is also the chance to set up some prefixes for working on more project within one svn repository, but from my current point of view it is only possible if you got the - |-Projekt A ||-trunk ||-tags | -branches |-Projekt B ||-trunk ||-tags | -branches structure. (Still needs some investigation of me ;) )
IMHO the biggest advantage is to work without connection to network and commit changes local and send them to the svn repo after I'm back in network. But this could be also done by svk ;)
Regards, Frank
On Fri, 20 Jun 2008 14:58:20 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
I'm using git-svn instead of svn for working with the geany-plugin repository. It combines the advantages of git (branching, fast, local copy of complete history) with the given svn repository. Because of this it feels like a normal git repository, but with the chance to commit to the central svn repository.
Cool, I didn't know about this, thanks.
...
only possible if you got the
|-Projekt A ||-trunk ||-tags | -branches structure. (Still needs some investigation of me ;) )
I'd prefer plugins didn't use this structure, as it's useful to checkout the whole of geany-plugins/trunk (particularly now Enrico's added his great waf build system), and if plugins did this you'd get a huge tree and it would take a longer time to checkout.
Regards, Nick
On Fri, 20 Jun 2008 14:58:20 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
Hi,
On Fri, June 20, 2008 2:39 pm, Nick Treleaven wrote:
On Fri, 20 Jun 2008 14:30:13 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
I think it's not a big deal to add these lines and give some more overview, e.g. if you working with git as frontend for geany-plugin.
Can you explain more about this? How does it work?
I'm using git-svn instead of svn for working with the geany-plugin repository. It combines the advantages of git (branching, fast, local copy of complete history) with the given svn repository. Because of this it feels like a normal git repository, but with the chance to commit to the central svn repository.
I work this way too. ;-)
But no prefix is really needed this way too. You can always clone each plugin independently:
git-svn clone https://<repo path>/trunk/<your plugin>
and have clean history tree for every plugin.
You can't work with svn branches and tags but I don't think it is big problem since you can do branch work with git. As for tags it is not very often operation.
On Fri, June 20, 2008 7:05 pm, Yura Siamashka wrote:
On Fri, 20 Jun 2008 14:58:20 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
Hi,
On Fri, June 20, 2008 2:39 pm, Nick Treleaven wrote:
On Fri, 20 Jun 2008 14:30:13 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
I think it's not a big deal to add these lines and give some more overview, e.g. if you working with git as frontend for geany-plugin.
Can you explain more about this? How does it work?
I'm using git-svn instead of svn for working with the geany-plugin repository. It combines the advantages of git (branching, fast, local copy of complete history) with the given svn repository. Because of this it feels like a normal git repository, but with the chance to commit to the central svn repository.
I work this way too. ;-)
But no prefix is really needed this way too. You can always clone each plugin independently:
git-svn clone https://<repo path>/trunk/<your plugin>
and have clean history tree for every plugin.
That is true. I'm using this already for combnining the old version history that was on git and the svn repo for it. A bad thing on that is, that I don't have to svn branches and svn tags inside the repository.
Frank
On Sun, June 22, 2008 12:06 pm, Frank Lanitz wrote:
On Fri, June 20, 2008 7:05 pm, Yura Siamashka wrote:
On Fri, 20 Jun 2008 14:58:20 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
Hi,
On Fri, June 20, 2008 2:39 pm, Nick Treleaven wrote:
On Fri, 20 Jun 2008 14:30:13 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
I think it's not a big deal to add these lines and give some more overview, e.g. if you working with git as frontend for geany-plugin.
Can you explain more about this? How does it work?
I'm using git-svn instead of svn for working with the geany-plugin repository. It combines the advantages of git (branching, fast, local copy of complete history) with the given svn repository. Because of this it feels like a normal git repository, but with the chance to commit to the central svn repository.
I work this way too. ;-)
But no prefix is really needed this way too. You can always clone each plugin independently:
git-svn clone https://<repo path>/trunk/<your plugin>
and have clean history tree for every plugin.
That is true. I'm using this already for combnining the old version history that was on git and the svn repo for it.
Well....sent on half way.
I wanted to add that I'm using this at GeanySendMail-plugin ;)
So far, Frank
On Sun, 22 Jun 2008 12:06:05 -0000 (UTC), "Frank Lanitz" frank@frank.uvena.de wrote:
On Fri, June 20, 2008 7:05 pm, Yura Siamashka wrote:
On Fri, 20 Jun 2008 14:58:20 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
Hi,
On Fri, June 20, 2008 2:39 pm, Nick Treleaven wrote:
On Fri, 20 Jun 2008 14:30:13 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
I think it's not a big deal to add these lines and give some more overview, e.g. if you working with git as frontend for geany-plugin.
Can you explain more about this? How does it work?
I'm using git-svn instead of svn for working with the geany-plugin repository. It combines the advantages of git (branching, fast, local copy of complete history) with the given svn repository. Because of this it feels like a normal git repository, but with the chance to commit to the central svn repository.
I work this way too. ;-)
But no prefix is really needed this way too. You can always clone each plugin independently:
git-svn clone https://<repo path>/trunk/<your plugin>
and have clean history tree for every plugin.
That is true. I'm using this already for combnining the old version history that was on git and the svn repo for it. A bad thing on that is, that I don't have to svn branches and svn tags inside the repository.
Tags are mainly intended for creating snapshots of certain revisions, e.g. when making a release. This should be a rather seldom used task, so I guess it's reasonable to do it using Subversion. Regarding branching: Don't get me wrong but as you told me before, you are very little on spare time, your plugins currently don't compile because of recent API changes and you still didn't fix them. This is no problem at all but when you are requesting a layout change to be able to create/use branches more easy using GIT, I assume you heavily want to actively work on the code...sounds inconsistent to me: you don't have the time to do a 3-minutes fix while you want branching your code for heavy development?
Regards, Enrico
Hi,
On Mon, 23 Jun 2008 17:18:55 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Tags are mainly intended for creating snapshots of certain revisions, e.g. when making a release. This should be a rather seldom used task, so I guess it's reasonable to do it using Subversion.
Tags are also a way to find a special version much faster.
Was just an idea, based on some kind of best practice from my work place. We are working on >100 homepages from inside a single subversion repository with >>10k commits /year. All commits are containing the name and number of a home page as well as a number of the tracking tool. Something like that »GeanySendMail: Update of Geany API (DEV-0815)« This makes it much easier to find a special commit and check, what was done there.
Cheers, Frank
Nick Treleaven a écrit :
On Fri, 20 Jun 2008 11:43:50 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
Hi,
Since most of the Geany plugins were moved to the 'central' plugin repository, I'd like to suggest to add the plugin name onto the commit message in the first line. This would make it much easier for somebody that is looking for a special commit than to have something like this:
r101: Compilation fixes r102: Compilation fixes r103: Compilation fixes r104: Compilation fixes
With the prefix there would be something like that:
r101: Plugin A: Compilation fixes r102: Plugin B: Compilation fixes r103: Plugin C: Compilation fixes r104: Plugin D: Compilation fixes
Opinions?
Well, it would be quite annoying to have to type the plugin name each time. If someone was looking for a commit for a specific plugin, wouldn't they just use 'svn log plugindir' rather than for the whole trunk?
Regards, Nick
What about an svn hook wich would look up wich directories were modified ? Of course this would be tweaked to handle cases where multiple plugins are modified at once (if this exists).
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 20 Jun 2008 18:34:26 +0200, Jean-Philippe skateinmars@skateinmars.net wrote:
Nick Treleaven a écrit :
On Fri, 20 Jun 2008 11:43:50 -0000 (UTC) "Frank Lanitz" frank@frank.uvena.de wrote:
Hi,
Since most of the Geany plugins were moved to the 'central' plugin repository, I'd like to suggest to add the plugin name onto the commit message in the first line. This would make it much easier for somebody that is looking for a special commit than to have something like this:
r101: Compilation fixes r102: Compilation fixes r103: Compilation fixes r104: Compilation fixes
With the prefix there would be something like that:
r101: Plugin A: Compilation fixes r102: Plugin B: Compilation fixes r103: Plugin C: Compilation fixes r104: Plugin D: Compilation fixes
Opinions?
Well, it would be quite annoying to have to type the plugin name each time. If someone was looking for a commit for a specific plugin, wouldn't they just use 'svn log plugindir' rather than for the whole trunk?
Regards, Nick
What about an svn hook wich would look up wich directories were modified ? Of course this would be tweaked to handle cases where
This would have to be done locally, on the developer's machine as we can't add own hook scripts on the Sourceforge SVN repository :(. But maybe GIT does provide something similar to handle this. Anyway, for me it's enough to read the commit messages to know where a change has been taken place.
multiple plugins are modified at once (if this exists).
IMO this should be avoided if possible.
Regards, Enrico